CVE-2026-90000: Linux Kernel HID-RMI Buffer Overflow

CVE-2026-90000 Overview

CVE-2026-90000 is an out-of-bounds access vulnerability in the Linux kernel's hid-rmi driver. The driver sizes its writeReport and readReport buffers directly from the report descriptor supplied by the device, with no minimum bound enforced. A device declaring undersized input or output reports causes fixed-offset reads and writes to overflow the allocation into adjacent slab objects. The read path is worse because the copy length is device-controlled through readReport[1] and can reach 255 bytes. Exploitation leaks kernel heap contents to unprivileged userspace through the product_id sysfs attribute and back to the device via the interrupt mask.

Critical Impact

A malicious or malformed HID device on the adjacent USB or Bluetooth bus can trigger heap-based out-of-bounds reads and writes in kernel memory, leading to information disclosure, memory corruption, and potential code execution.

Affected Products

• Linux kernel — drivers/hid/hid-rmi.c (RMI over HID transport)
• Multiple stable kernel branches referenced by the fix commits
• Any Linux system exposing HID device attach paths (USB, Bluetooth, I2C-HID)

Discovery Timeline

• 2026-09-16 - CVE-2026-90000 published to NVD
• 2026-09-16 - Last updated in NVD database

Technical Details for CVE-2026-90000

Vulnerability Analysis

The hid-rmi driver allocates a combined buffer using alloc_size = output_report_size + input_report_size, then places readReport at writeReport + output_report_size. Both sizes come from hid_report_len() applied to descriptors the device controls. A device declaring a one-byte output and one-byte input report yields an alloc_size of only four bytes.

The driver then writes fixed offsets into the buffer regardless. rmi_set_page() stores writeReport[4], and rmi_hid_read_block() writes writeReport[0..5]. These writes corrupt the adjacent readReport window where the next reply is parsed. On the read path, the copy length is taken from readReport[1], which the device fills and can set up to 255. The copy begins at &readReport[2] without checking input_report_size, running past the allocation into neighboring slab objects.

Even honest devices are affected. rmi_f01_probe() issues a fixed 21-byte register read, so any device declaring an input report smaller than 23 bytes reads out of bounds. Those bytes then feed the RMI core: they are printed to the kernel log, exported through the mode 0444product_id sysfs attribute, and sent back to the device by rmi_driver_set_irq_bits() as the interrupt mask.

Root Cause

The root cause is missing minimum-size validation on device-supplied HID report descriptors combined with device-controlled copy lengths. The driver trusts descriptor values for allocation sizing but uses hardcoded offsets for access. A secondary defect exists in the read loop, which cannot terminate on a zero-length reply because neither bytes_read nor bytes_needed advances and the wake-up bypasses the one-second wait_event_timeout().

Attack Vector

Exploitation requires an attacker to attach a malicious or crafted HID device to the target. This is feasible over adjacent transports including USB, Bluetooth HID, and I2C-HID. A rogue peripheral declares undersized RMI input and output reports, then returns crafted length bytes and payload data to trigger heap corruption or leak memory. Attack complexity is low and no authentication is required once the device is enumerated. The vulnerability class is Out-of-Bounds Write and Out-of-Bounds Read in kernel context.

No public proof-of-concept code has been published. The vulnerability is described in prose in the upstream commit messages linked in the references.

Detection Methods for CVE-2026-90000

Indicators of Compromise

• Kernel log messages from hid-rmi probe referencing unusually short input or output report sizes
• Slab corruption reports (KASAN, SLUB debug) originating in rmi_hid_read_block, rmi_set_page, or rmi_f01_probe
• Contents of /sys/bus/hid/devices/*/product_id containing non-printable bytes or values inconsistent with vendor documentation
• Unexpected HID devices claiming the Synaptics RMI report IDs on hosts that do not use Synaptics touchpads

Detection Strategies

• Enable CONFIG_KASAN on test kernels to surface out-of-bounds accesses in hid-rmi during device attach
• Audit dmesg for hid-rmi probe messages correlated with USB or Bluetooth HID device connect events
• Monitor kernel oops and panic events tagged to the hid-rmi module or the HID subsystem during peripheral enumeration

Monitoring Recommendations

• Alert on new HID device attachments on servers and workstations where physical peripheral changes are unexpected
• Track kernel version and module load state to identify hosts still running unpatched hid-rmi builds
• Correlate USB and Bluetooth pairing events with subsequent kernel warnings or crashes

How to Mitigate CVE-2026-90000

Immediate Actions Required

• Apply the upstream kernel patches referenced in the CVE record and rebuild or update to a fixed stable release
• Blacklist the hid_rmi module on systems that do not require Synaptics RMI touchpad support using /etc/modprobe.d/
• Restrict physical and wireless access to endpoints, and disable Bluetooth HID pairing where not required

Patch Information

The fix rejects reports too small for what the driver builds — six output bytes for write reports and three input bytes for the read handshake — at probe time. It clamps write and read copies to the device-declared report sizes and treats a zero-length reply as an error. RMI_DEVICE is stripped from driver_data before the report checks, and RMI_READ_DATA_PENDING is cleared on the error path. The upstream commits are available at Kernel Git Commit 056ef8e, Kernel Git Commit 183da10, Kernel Git Commit 48934c2, Kernel Git Commit 4956993, Kernel Git Commit a8be8bb, Kernel Git Commit ab2958e, Kernel Git Commit f4cb9c4, and Kernel Git Commit fba600d.

Workarounds

• Blacklist the driver where it is not needed by writing blacklist hid_rmi to a file under /etc/modprobe.d/ and rebuilding the initramfs
• Enforce USB device access controls with USBGuard policies that permit only known-good HID vendors and product IDs
• Disable Bluetooth on hosts that do not require it, and require user confirmation for new HID pairings on those that do

# Configuration example
# Prevent the vulnerable hid-rmi module from loading
echo "blacklist hid_rmi" | sudo tee /etc/modprobe.d/blacklist-hid-rmi.conf
sudo update-initramfs -u

# Verify the module is not loaded
lsmod | grep hid_rmi