CVE-2026-80569

Input: synaptics-rmi4 - bound the F54 report size to the allocated buffer

HIGH
7.8
CVSS Score
Published: August 26, 2026 at 02:37 PM UTC
Updated: August 27, 2026 at 06:30 AM UTC
1 product affected across 1 vendorLinux Kernel

Using Linux by Linux?

Get instant alerts when new vulnerabilities affect Linux - before attackers find them.

Real-time alertsTrack your software stackFree plan available
Severity
HIGH7.8
Exploit prediction
EPSS 0.1%

Description

In the Linux kernel, the following vulnerability has been resolved: Input: synaptics-rmi4 - bound the F54 report size to the allocated buffer rmi_f54_work() reads a diagnostics report from the device into f54->report_data, sizing the transfer with rmi_f54_get_report_size(): report_size = rmi_f54_get_report_size(f54); ... for (i = 0; i < report_size; i += F54_REPORT_DATA_SIZE) { int size = min(F54_REPORT_DATA_SIZE, report_size - i); ... rmi_read_block(.., f54->report_data + i, size); } report_data is allocated once at probe from F54's own electrode counts (array3_size(f54->num_tx_electrodes, f54->num_rx_electrodes, sizeof(u16))), but rmi_f54_get_report_size() computes the size from drv_data->num_*_electrodes when those are set, i.e. from the F55 function's electrode counts. Both counts come straight from device queries (F54 and F55 each report up to 255 electrodes) and nothing constrains the F55 counts to the F54 ones. A malicious or malfunctioning RMI4 device that reports larger F55 electrode counts than its F54 counts makes report_size exceed the allocation, so the read loop writes past report_data (and the V4L2 dequeue memcpy() then reads past it). On conforming hardware the F55 configured electrodes are a subset of the F54 physical electrodes, so report_size never exceeds the buffer and well-behaved devices are unaffected. Record the allocation size and reject a report that does not fit, mirroring the existing zero-size check.

Affected

Our own answer: ranges merged, affected separated from platform-only, with confidence and review flags.

4.10 ≤ v < 5.10.2664.10 ≤ v < 5.15.2174.10 ≤ v < 6.1.1844.10 ≤ v < 6.12.1054.10 ≤ v < 6.18.464.10 ≤ v < 6.6.1534.10 ≤ v < 7.1.104.10 ≤ v < 7.24.10c762cc68b6a12eedebefc156ea4838e54804e2eb
Vendor states this is fixed in 12be3c6ca9589afd6ade41a59c761866e526634d (fixed)
Vendor states this is fixed in 42eaf0e6f79c487f419737314cf0760f7331d368 (fixed)
Vendor states this is fixed in 49c5adc2b7d6e43c5cf033e1c86fdb9c16ababb1 (fixed)
Vendor states this is fixed in 6b06aab79ff166d5781ce792d91acc2e58b1770b (fixed)
Vendor states this is fixed in 6b3bdd44d4cd7d5e35de1d0f06d4930f3cecd403 (fixed)
Vendor states this is fixed in b2f596f00d27703ce09167201ba57f55be8d2f9a (fixed)
Vendor states this is fixed in b3932101c9c457148038392bc977f9b31e125a86 (fixed)
Vendor states this is fixed in b7b9a8b1c303b62371698e396654d6724c79cb74 (fixed)
Vendor states this is fixed in 4.10 (unaffected)
Vendor states this is fixed in 5.10.266 (unaffected)
Vendor states this is fixed in 5.15.217 (unaffected)
Vendor states this is fixed in 6.1.184 (unaffected)
Vendor states this is fixed in 6.12.105 (unaffected)
Vendor states this is fixed in 6.18.46 (unaffected)
Vendor states this is fixed in 6.6.153 (unaffected)
Vendor states this is fixed in 7.1.10 (unaffected)
Vendor states this is fixed in 7.2 (unaffected)

Remediation

No guide yet

No remediation guidance has been written for this CVE yet, and no fixed version or vendor advisory is recorded against it.

CVSS

7.8HIGHLinux
Vector?

Quick Info

StatusRECEIVED

Get alerted

Stop reading CVE feeds looking for your own stack

Track the products you run and VulnTracker tells you when a new CVE affects them — with what is known about fixing it, and nothing about the rest.

Free plan, no card