CVE-2026-80570 in Linux
Summary
by MITRE • 08/26/2026
In the Linux kernel, the following vulnerability has been resolved:
Input: synaptics-rmi4 - zero report size on F54 work error
In rmi_f54_work(), if an error occurs during report request or command verification, the code jumped directly to the 'error' label, bypassing the 'abort' label where f54->report_size was normally zeroed out.
This left f54->report_size containing its previous successful payload size. If a user then altered the V4L2 format to a smaller size, and a subsequent run failed, rmi_f54_buffer_queue() would copy the stale, larger payload size into the shrunken V4L2 buffer, causing a heap buffer overflow.
Fix this by merging the 'abort' and 'error' labels into a single 'out' exit path, and ensuring that f54->report_size is always set to 0 on failure by checking for error and zeroing the local report_size first.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 08/26/2026
The vulnerability identified in the Linux kernel's synaptics-rmi4 driver represents a critical heap buffer overflow condition arising from improper state management during error handling sequences within the F54 touch sensor firmware interface. This specific flaw is located in the rmi_f54_work function, which processes data reports from Synaptics RMI4 devices. The core technical issue stems from an inconsistent code path when errors occur during report requests or command verification steps. Under normal operation, if a process reaches the abort state, it correctly zeroes out the f54->report_size variable to indicate that no valid payload is pending. However, in error scenarios, the original implementation bypassed this critical cleanup step by jumping directly to an error label without resetting the report size counter. This oversight leaves the driver with stale data from a previous successful transaction, creating a discrepancy between the actual available buffer space and the amount of data the kernel attempts to copy into user-space buffers.
The operational impact of this vulnerability is severe due to its potential for remote or local exploitation depending on the device context. When an error occurs in subsequent operations, the rmi_f54_buffer_queue function proceeds to copy data based on the stale f2->report_size value rather than verifying the actual available space. If a user-space application has altered the V4L2 format to request a smaller buffer size, and the kernel subsequently attempts to write the larger, previously cached payload into this shrunken buffer, a heap-based buffer overflow occurs. This type of memory corruption can lead to arbitrary code execution with the privileges of the kernel process context, potentially allowing an attacker who has access to the device or input subsystem to escalate privileges, crash the system through denial-of-service conditions, or leak sensitive kernel memory contents by overwriting adjacent heap structures and manipulating control flow data.
From a classification perspective, this vulnerability aligns closely with CWE-120 Buffer Copy without Checking Size of Input Classic buffer overflow, specifically manifesting as a heap-based overflow due to the location of the corrupted memory region. The failure to properly validate input sizes against allocated buffers before copying data is a fundamental security design flaw often associated with CWE-20 Improper Input Validation. Furthermore, in the context of attack techniques, this vulnerability facilitates exploitation paths similar to those described in MITRE ATT&CK technique T1059 Command and Scripting Interpreter or more specifically memory corruption primitives that enable privilege escalation such as T1068 Exploitation for Privilege Escalation. The lack of proper state reset on error conditions also reflects CWE-377 Insecure Temporary File which, while typically associated with file systems, conceptually parallels the insecure handling of temporary in-memory states that are not properly sanitized after use or failure.
The resolution implemented by merging the abort and error labels into a single out exit path ensures consistent cleanup logic regardless of how the function terminates. By guaranteeing that f54->report_size is explicitly set to zero on any failure, including those detected during report requests or command verification, the driver prevents the propagation of stale payload sizes. This fix eliminates the possibility of copying oversized data into undersized V4L2 buffers. To mitigate similar risks in other drivers and subsystems, developers should enforce strict state sanitization upon error paths, ensuring that all mutable state variables related to buffer lengths are reset before exiting critical sections. Additionally implementing rigorous bounds checking on every memory copy operation involving user-supplied or dynamically determined sizes is essential for maintaining kernel integrity. Regular static analysis tools configured to detect CWE-120 patterns can help identify such oversights early in the development lifecycle, reducing the attack surface of input-heavy subsystems like HID and multimedia drivers.