CVE-2026-89628

What it actually does

The hid_picolcd debugfs EEPROM read path trusts a device-supplied length byte in a REPORT_EE_DATA reply and does not clamp it to the number of bytes actually received into the pending response buffer. A crafted or spoofed picoLCD HID device can cause copy_to_user() to read past the 64-byte raw_data[] slab allocation and return adjacent kernel heap contents to a privileged userspace reader of the debugfs eeprom file. Impact is local kernel information disclosure (slab OOB read), not remote code execution. The file is root-only (S_IRUSR) and a malicious HID device is required, so the issue is neither unprivileged nor network-triggerable.

Why it matters to the business

Practical business risk is low: there is no CISA KEV listing, no ransomware association, and no public exploit maturity 38 days after publication. Exploitation requires physical USB (or equivalent USB passthrough/VM) access plus a privileged process reading picoLCD debugfs, so it does not enable remote compromise of internet-facing services. Residual concern is leakage of kernel heap data (pointers, residual secrets) that could aid a follow-on local attack on systems that attach untrusted USB HID devices and load hid_picolcd. Organizations without picoLCD hardware or with the module unused face negligible operational impact beyond routine kernel patching.

How an attack unfolds

An attacker who can present a USB HID device that the kernel binds as picoLCD supplies a REPORT_EE_DATA reply whose length byte claims far more payload than was actually copied into the kmalloc'd pending buffer. When a root-equivalent process reads the debugfs eeprom file, the driver copies that claimed length (capped only by the userspace read count, not by raw_size) from raw_data+3 into userspace, including adjacent slab memory. The leaked bytes are then available to the attacker on the same host. No named threat actors or in-the-wild campaigns are associated with this CVE; the attack is local, device-dependent, and not remotely triggerable.

How to fix it

Apply the Linux kernel fix that clamps the EEPROM debugfs copy length to max(0, resp->raw_size - 3) so the driver never copies more payload than picolcd_raw_event() actually stored. Deploy the patched kernel from your distribution or vendor as soon as it is available; no per-package version list was supplied with this record, so track distro advisories for hid_picolcd / linux-image updates that mention this HID picolcd EEPROM clamp. Until patched, unload or blacklist hid_picolcd on hosts that do not need picoLCD hardware, keep debugfs restricted to root, and enforce USB device authorization / allowlisting so untrusted HID gadgets cannot bind. Do not rely on the S_IRUSR debugfs mode alone as a complete mitigation if untrusted USB devices are accepted.

How to confirm the fix worked

Confirm the running kernel includes the picolcd EEPROM clamp (vendor changelog, git commit for HID picolcd, or distro CVE mapping). Verify hid_picolcd is absent from lsmod on systems that should not use it, and that debugfs picoLCD eeprom nodes are not present or remain root-only. After patching, regression-check that legitimate picoLCD EEPROM debug reads still return only the received payload and that kernel memory sanitizers no longer report slab-out-of-bounds in picolcd_debug_eeprom_read. Review USB allowlists to ensure unknown HID picoLCD-class devices cannot enumerate on production hosts.

Typical attack path

1. Gain physical USB access, USB passthrough, or equivalent ability to attach a HID device the host will bind to hid_picolcd.
2. Present a crafted or spoofed picoLCD that answers EEPROM reads with an oversized length byte relative to the bytes actually received.
3. Cause a privileged process to read the picoLCD debugfs eeprom node (root-only).
4. Receive out-of-bounds kernel slab contents in the read buffer.
5. Use any leaked kernel pointers or residual heap data only as a local information source for further attacks on the same machine.

How to detect it

This leak may leave no reliable network IOC. Hunt hosts that loaded hid_picolcd and had debugfs picoLCD eeprom reads around suspicious USB HID enumeration. On kernels with KASAN or similar, look for slab-out-of-bounds reads in _copy_to_user attributed to picolcd_debug_eeprom_read in hid_picolcd. Review kernel logs for picoLCD / HID bind events from unexpected USB devices, debugfs access to eeprom nodes under the picoLCD debug directory, and USB authorization denials or unexpected HID gadget attach. Absence of those logs does not prove non-exploitation because a successful copy_to_user of adjacent slab need not oops on non-KASAN kernels.

• picolcd_debug_eeprom_read
• hid_picolcd
• KASAN: slab-out-of-bounds in _copy_to_user
• slab-out-of-bounds in picolcd_debug_eeprom_read
• REPORT_EE_DATA
• /sys/kernel/debug/picolcd
• debugfs eeprom
• picolcd_raw_event

What your security team should do

• Patch Linux kernels to the hid_picolcd EEPROM length-clamp fix via normal distro/vendor kernel updates; this is not a KEV emergency but should ride the next kernel cycle.
• Inventory whether hid_picolcd is loaded and whether picoLCD devices are in use; unload or blacklist the module where unused.
• Treat untrusted USB HID attachment (kiosks, labs, VMs with USB passthrough, developer laptops) as the relevant exposure surface and enforce USB allowlisting.
• Do not prioritize this as a remote or ransomware-driven incident; there is no KEV entry, no ransomware use, and exploit maturity is none.
• After patching, hunt historically for KASAN/slab-OOB traces naming picolcd_debug_eeprom_read on hosts that had the module loaded.