CVE-2026-80569 in Linux
Summary
by MITRE • 08/26/2026
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.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/26/2026
The Linux kernel driver for Synaptics RMI4 touchscreens contains a critical out-of-bounds write vulnerability within the F54 diagnostics reporting mechanism. This flaw arises from an inconsistency in how buffer sizes are calculated versus how they are allocated during device initialization. Specifically, the memory buffer f54->report_data is allocated based on the electrode counts reported by the F54 function of the RMI4 device. However, when processing diagnostic reports via rmi_f54_work(), the size of the data to be read is determined by rmi_f54_get_report_size(). This function incorrectly derives its calculation from drv_data->num_*_electrodes, which corresponds to the F55 function's electrode configuration rather than the F54 function used for allocation. Since both sets of counts are queried directly from the hardware and can independently report up to 255 electrodes without mutual constraint, a discrepancy between these values creates a dangerous condition where the calculated transfer size exceeds the allocated buffer capacity.
This architectural mismatch allows an attacker or a malfunctioning device with larger F55 electrode counts than its F54 counterpart to trigger a heap-based buffer overflow. As the driver iterates through the report data using rmi_read_block, it writes past the end of f54->report_data into adjacent memory regions. The vulnerability is further exacerbated because this corrupted data is subsequently processed by V4V2 subsystem components that dequeue and copy the malformed information, potentially leading to additional out-of-bounds reads or arbitrary code execution depending on the contents of the overwritten memory. On conforming hardware where F55 configured electrodes are strictly a subset of physical F54 electrodes, this issue does not manifest; however, non-compliant devices can exploit this logic error to compromise kernel stability and security.
From a classification perspective, this vulnerability aligns with CWE-120 Buffer Copy without Checking Size of Input in C/C++, as the code performs memory operations based on input-derived sizes without verifying that those sizes fit within the pre-allocated buffer boundaries. In terms of attack vectors, it relates to ATT&CK technique T1564 Hidden Elements or potentially T1059 Command and Scripting Interpreter if exploited for privilege escalation through kernel exploitation chains. The root cause is a failure in input validation where external device data influences internal memory management decisions without adequate bounds checking relative to the actual allocation size.
To mitigate this vulnerability, it is essential to enforce strict consistency between buffer allocation sizes and read operations. The recommended fix involves recording the exact allocation size of f54->report_data during the probe phase and validating that any incoming report from rmi_f54_get_report_size() does not exceed this recorded limit before initiating data transfers. This approach mirrors existing safety checks for zero-size reports but extends protection against oversized inputs derived from mismatched hardware capabilities. By rejecting reports that do not fit within the allocated buffer, the driver prevents out-of-bounds writes and maintains memory integrity regardless of whether the connected device is well-behaved or maliciously configured.