CVE-2026-64277: Linux Kernel Information Disclosure Bug

CVE-2026-64277 Overview

CVE-2026-64277 is a Linux kernel vulnerability in the synaptics-rmi4 input driver. The rmi_f3a_initialize() function reads a GPIO count from a device query register with a valid range of 0 to 127. However, rmi_f3a_map_gpios() allocates the gpio_key_map array with at most 6 entries, while input->keycodemax is set to the full gpio_count. A malicious or malfunctioning device reporting gpio_count > 6 triggers out-of-bounds reads on every attention interrupt and enables out-of-bounds access through the input core's default keymap ioctls.

Critical Impact
Any local process able to open the affected evdev node can leak adjacent slab memory via EVIOCGKEYCODE and write attacker-controlled values past the buffer via EVIOCSKEYCODE, enabling kernel memory disclosure and potential privilege escalation.

Affected Products

Linux kernel builds including the synaptics-rmi4 input driver with F3A function support
Multiple stable kernel branches receiving the backported fix (see referenced commits)
Systems paired with Synaptics RMI4 touchpad or trackstick devices exposing the F3A function

Discovery Timeline

2026-07-25 - CVE-2026-64277 published to NVD
2026-07-30 - Last updated in NVD database

Technical Details for CVE-2026-64277

Vulnerability Analysis

The flaw resides in the Synaptics RMI4 F3A function handler in the Linux input subsystem. The driver reads gpio_count from the device query register with f3a->gpio_count = buf & RMI_F3A_GPIO_COUNT, allowing values from 0 to 127. The allocation for gpio_key_map uses min(gpio_count, TRACKSTICK_RANGE_END), which caps at 6 entries. The mismatch between the allocation size and the exposed keycodemax value creates the out-of-bounds condition.

When rmi_f3a_attention() fires, it iterates the full gpio_count and dereferences gpio_key_map[i] beyond the 6-entry allocation. Additionally, input->keycode points at the small allocation while input->keycodemax reflects the unbounded gpio_count. The input core's default keymap accessors input_default_getkeycode() and input_default_setkeycode() bound access only against keycodemax, permitting reads and writes past the allocated buffer.

Root Cause

The root cause is inconsistent bounds tracking between the allocated gpio_key_map buffer and the keycodemax value exposed to userspace ioctls. This is classified as an Out-of-Bounds Read and Out-of-Bounds Write condition rooted in improper input validation of device-reported values.

Attack Vector

Exploitation requires local access and the ability to open the evdev character device node for the affected input device. An attacker with EVIOCGKEYCODE access can read adjacent slab memory, leaking kernel data to userspace. Using EVIOCSKEYCODE, the attacker writes caller-controlled values into slab memory beyond the allocation. A malicious or spoofed USB RMI4 device that reports gpio_count > 6 is also required to trigger the attention-path out-of-bounds reads.

The vulnerability is described in prose only; refer to the referenced kernel commits for the precise patch diff.

Detection Methods for CVE-2026-64277

Indicators of Compromise

Unexpected evdev ioctl activity (EVIOCGKEYCODE, EVIOCSKEYCODE) from non-privileged processes targeting Synaptics RMI4 input nodes
Kernel log messages or KASAN reports referencing rmi_f3a_attention or gpio_key_map out-of-bounds access
Presence of unusual USB or I2C HID devices identifying as Synaptics RMI4 with abnormally high reported GPIO counts

Detection Strategies

Enable KASAN on test and staging kernels to surface out-of-bounds reads in rmi_f3a_attention() and the input keymap accessors
Audit running kernel versions against the patched commits listed in the references to identify unpatched hosts
Monitor for processes opening /dev/input/event* nodes that do not belong to expected desktop or accessibility software

Monitoring Recommendations

Log and alert on ioctl syscalls against /dev/input/event* from unexpected UIDs using auditd rules
Track USB device enumeration events for newly attached HID devices reporting Synaptics RMI4 F3A functionality
Correlate kernel oops, panic, or KASAN entries with local process activity to identify exploitation attempts

How to Mitigate CVE-2026-64277

Immediate Actions Required

Apply the upstream Linux kernel patches referenced by commits 3480e24b, 35ed74d3, 502ad7ca, 57c10915, 64fb0e11, 850117b6, 8db211ae, and ba57f430 for the appropriate stable branch
Restrict access to /dev/input/event* device nodes so that only privileged processes and the interactive user session can open them
Disable the synaptics_rmi4 and related F3A modules on servers or systems that do not require Synaptics touchpad support

Patch Information

The fix sizes gpio_key_map for the full gpio_count value read from the device. The mapping loop remains unchanged, assigning only the first min(gpio_count, TRACKSTICK_RANGE_END) entries, while the remaining slots stay KEY_RESERVED because devm_kcalloc() zero-fills the allocation. See the Linux Kernel Commit 3480e24 and the additional stable-branch commits in the references.

Workarounds

Blacklist the rmi_core and rmi_smbus kernel modules on systems that do not use Synaptics RMI4 hardware
Enforce strict udev rules limiting group membership on evdev nodes to reduce the set of processes that can invoke EVIOCGKEYCODE and EVIOCSKEYCODE
Disable USB device auto-binding for untrusted ports using USBGuard or similar controls to prevent malicious devices from attaching

bash

# Blacklist the RMI4 modules until the kernel is patched
echo 'blacklist rmi_core' | sudo tee /etc/modprobe.d/blacklist-rmi.conf
echo 'blacklist rmi_smbus' | sudo tee -a /etc/modprobe.d/blacklist-rmi.conf
sudo update-initramfs -u