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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.8",
  "pubDate": "2026-08-26T15:17:12.457Z",
  "pubdate": "2026-08-26T15:17:12.457Z",
  "executiveSummary": "A heap-based buffer overflow vulnerability exists in the Linux kernel's synaptics-rmi4 driver due to insufficient bounds checking on diagnostic report sizes.\nThe vulnerability occurs within the F54 function, where data received from an RMI4 device is written into a pre-allocated buffer without verifying that the device-reported size matches the actual allocated memory capacity.\nThis flaw allows a malicious or malfunctioning hardware device to trigger an out-of-bounds memory write, potentially leading to kernel memory corruption.\nThe impact includes system instability, potential local privilege escalation (LPE), or denial of service (DoS) by overwriting adjacent kernel data structures.\nExploitation requires physical access or the ability to communicate with an RMI4-compliant input device, as the driver accepts data directly from device firmware queries.\nThe risk is primarily relevant to systems using hardware that allows for arbitrary or malicious firmware reporting, such as compromised or adversarial RMI4-compatible peripherals.",
  "technicalDetails": "The root cause of this vulnerability is a mismatch between the memory allocated for the 'f54->report_data' buffer and the data size calculation performed in 'rmi_f54_work()'.\nDuring initialization in the probe function, the buffer is allocated based on F54's electrode counts. However, the subsequent processing loop in 'rmi_f54_work()' relies on 'rmi_f54_get_report_size()', which dynamically derives the report size from F55 function electrode counts.\nBecause the driver does not enforce a constraint ensuring that F55 electrode counts remain consistent with or smaller than the F54 electrode counts used during initial allocation, an attacker-controlled device can report inflated electrode counts for F55.\nThe attack flow initiates when the kernel driver triggers an RMI4 diagnostic report read. The device, acting as a malicious peripheral, responds to queries with F55 electrode dimensions that exceed the buffer capacity.\nInside 'rmi_f54_work()', the loop iterates through the reported size: 'for (i = 0; i < report_size; i += F54_REPORT_DATA_SIZE)'. The code uses 'rmi_read_block()' to copy device-provided data into 'f54->report_data + i'.\nBecause 'report_size' can exceed the pre-allocated memory size, the loop writes beyond the boundaries of the 'report_data' buffer, causing heap corruption. Following this write, subsequent V4L2 dequeue operations may also perform memory access operations based on the corrupted state or continue to read/write out-of-bounds memory.\nThere is no authentication or privilege requirement for the attacker, other than the ability to connect a device that interfaces with the RMI4 kernel driver. Once the kernel initiates communication with the device, the malicious payload provided by the hardware is processed directly by the driver without validation.\nThe post-exploitation impact is severe, as kernel heap corruption can be leveraged by an attacker to overwrite sensitive kernel objects, function pointers, or data structures, leading to full system compromise or arbitrary code execution within the kernel context."
}