CVE-2026-80754 in Linux
Summary
by MITRE • 09/03/2026
In the Linux kernel, the following vulnerability has been resolved:
Input: synaptics-rmi4 - fix F55 transmitter electrode count typo
During F55 sensor detection, the transmitter (TX) electrode count was incorrectly assigned the value of the receiver (RX) electrode count due to copy-paste typos.
This incorrect value was then propagated to the driver data and used by F54 to determine the diagnostics report size. On devices with more RX than TX electrodes, this inflated the perceived TX count, leading to incorrect report size calculations and potential out-of-bounds buffer accesses.
Fix the typos by correctly assigning the TX electrode counts.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/03/2026
The Linux kernel input subsystem contains a critical logic error within the Synaptics RMI4 driver that affects devices utilizing F55 sensor technology, specifically those involving touchscreens or trackpads with distinct transmitter and receiver electrode arrays. The vulnerability stems from a copy-paste programming mistake during the initialization phase of the F55 sensor detection process. In these capacitive sensing systems, accurate enumeration of physical electrodes is fundamental for proper data acquisition and processing. The driver code erroneously assigned the value representing the number of receiver (RX) electrodes to the variable intended to store the count of transmitter (TX) electrodes. This misassignment occurs because RX and TX electrode counts are often retrieved from similar hardware registers or configuration blocks, making such a typo plausible during development but dangerous in production environments where these values dictate memory allocation and buffer sizing for subsequent diagnostic operations.
The operational impact of this flaw is significant due to the downstream dependencies on accurate electrode counts within the driver architecture. The incorrectly inflated transmitter count is propagated into the core driver data structures used by other components, most notably the F54 module which handles diagnostics reporting. When the system attempts to calculate the size required for a diagnostic report buffer, it relies on these erroneous values. On devices where the number of receiver electrodes exceeds the number of transmitter electrodes, this typo results in an overestimation of the TX count. Consequently, the driver may allocate buffers based on incorrect dimensions or attempt to access memory regions that do not correspond to valid data structures for the actual hardware configuration. This discrepancy creates a pathway for out-of-bounds buffer accesses, which can lead to kernel panics, system instability, or potentially exploitable conditions if an attacker can influence the input stack in specific ways to trigger these malformed calculations during runtime operations such as touch event processing or diagnostic polling.
From a vulnerability classification perspective, this issue aligns with CWE-190 Integer Overflow or Wraparound and CWE-787 Out-of-bounds Write when considering the potential for memory corruption resulting from incorrect size calculations based on flawed input data. It also relates to CWE-253 Incorrect Check of Function Return Value if the allocation fails silently, though the primary issue is logical rather than a failure check omission. In terms of attack vectors and techniques, this flaw could be leveraged in scenarios described by MITRE ATT&CK technique T1059 Command and Scripting Interpreter or more broadly under privilege escalation pathways where kernel memory corruption leads to arbitrary code execution. However, the primary risk remains system stability rather than direct remote exploitation, as it requires physical interaction with the device input subsystem to trigger the diagnostic routines that utilize these miscalculated sizes.
Mitigation strategies for this vulnerability involve both immediate patching and long-term defensive coding practices. The most effective remediation is applying the kernel update provided by the distribution vendor which corrects the variable assignment in the synaptics-rmi4 driver source code. Administrators should ensure their systems are updated to versions containing this fix, particularly if they utilize hardware from Synaptics or related manufacturers that implement RMI4 interfaces with F55 sensors. For developers and maintainers of similar input drivers, it is crucial to enforce strict type checking and validation during the initialization phase of sensor detection routines. Implementing unit tests that verify electrode counts against known hardware specifications can prevent such copy-paste errors from reaching production code. Additionally, adding runtime assertions or bounds checks when calculating buffer sizes based on dynamic hardware parameters would provide an extra layer of defense against potential out-of-bounds accesses even if a logical error persists in the enumeration logic.