CVE-2026-64276 in Linux
Summary
by MITRE • 07/25/2026
In the Linux kernel, the following vulnerability has been resolved:
Input: synaptics-rmi4 - bound the F30 keymap to the GPIO/LED count
rmi_f30_map_gpios() allocates gpioled_key_map with min(gpioled_count, TRACKSTICK_RANGE_END) == at most 6 entries, but rmi_f30_attention() iterates the full f30->gpioled_count (device query register, range 0..31) and dereferences gpioled_key_map[i], and
input->keycodemax is set to the full gpioled_count while input->keycode points at the 6-entry allocation.
A device that reports gpioled_count > 6 with GPIO support enabled therefore causes an out-of-bounds read on the attention interrupt and out-of-bounds read/write through the EVIOCGKEYCODE/EVIOCSKEYCODE ioctls, which bound the index only against keycodemax. This is the same defect as the F3A handler, which was copied from F30.
Size the keymap for the full gpioled_count; the mapping loop still assigns only the first min(gpioled_count, TRACKSTICK_RANGE_END) entries.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 07/25/2026
The vulnerability resides in the synaptics-rmi4 driver within the Linux kernel, specifically affecting how GPIO and LED mappings are handled for touchpad devices. This issue manifests as an out-of-bounds memory access condition that occurs during device initialization and interrupt processing. The flaw stems from a mismatch between the allocated memory size for the gpioled_key_map array and the actual number of GPIO/LED entries being processed, creating a scenario where device drivers can access memory beyond their intended bounds.
The technical implementation error occurs in the rmi_f30_map_gpios() function which properly limits the allocation of gpioled_key_map to a maximum of six entries using the TRACKSTICK_RANGE_END constant. However, the rmi_f30_attention() function fails to respect this limitation when processing device interrupts, instead iterating through the full gpioled_count value obtained from device query registers ranging from 0 to 31. This discrepancy creates a fundamental mismatch between memory allocation and access patterns, where the system processes more entries than allocated memory can safely accommodate.
The operational impact of this vulnerability extends beyond simple memory corruption to potentially enable privilege escalation or denial-of-service conditions within the kernel space. When devices report gpioled_count values greater than six while GPIO support is enabled, the out-of-bounds read during interrupt processing can lead to information disclosure or system instability. Additionally, the EVIOCGKEYCODE and EVIOCSKEYCODE ioctls provide an attack surface where index bounds checking only considers keycodemax rather than the actual allocated array size, allowing malicious actors to perform out-of-bounds write operations through ioctl calls.
This vulnerability aligns with CWE-129 Input Validation and CWE-787 Out-of-bounds Write categories within the Common Weakness Enumeration framework, representing a classic buffer over-read condition that can be exploited to gain unauthorized access to kernel memory. The flaw also maps to ATT&CK technique T1068, as it provides an avenue for privilege escalation through kernel memory corruption, and T1547.001 for potential persistence mechanisms. The issue was previously identified in the F3A handler where similar code patterns were copied from the F30 implementation, indicating a systemic problem in the driver's design architecture.
The recommended mitigation strategy involves expanding the gpioled_key_map allocation to match the full gpioled_count value while maintaining the existing mapping loop logic that only assigns values to the first min(gpioled_count, TRACKSTICK_RANGE_END) entries. This approach ensures proper memory allocation without altering the intended functionality of the GPIO/LED mapping process, effectively resolving the out-of-bounds access conditions while preserving the driver's operational integrity. The fix addresses both the interrupt processing path and ioctl handling mechanisms to provide comprehensive protection against this class of vulnerability.