CVE-2026-89628: HID: picolcd: clamp eeprom debugfs read to bytes actually received
In the Linux kernel, the following vulnerability has been resolved:
HID: picolcd: clamp eeprom debugfs read to bytes actually received
picolcddebugeepromread() trusts resp->rawdata[2] -- a length byte supplied by the device in its REPORTEEDATA reply -- clamped only to the caller's read() count:
ret = resp->rawdata[2]; if (ret > s) ret = s; if (copytouser(u, resp->rawdata+3, ret))
It never checks resp->rawsize, the number of bytes picolcdrawevent() actually copied into the 64-byte rawdata[] of the kmalloc'd struct picolcdpending. A device (or a spoofed picoLCD) returning a length byte of 0xff, read with a count >= 255, makes copytouser() read past rawdata[] into adjacent slab memory and return it to userspace through the debugfs "eeprom" file:
BUG: KASAN: slab-out-of-bounds in copytouser Read of size 255 ... picolcddebugeepromread+0x214/0x2f0 [hidpicolcd]
The debug-dump path in the same file already validates the device length byte against the received size before trusting it; this read does not. The file is created SIRUSR (root-only) and a crafted device is needed, so it is neither unprivileged- nor remotely-triggerable.
Clamp the copy length to resp->rawsize - 3 (the payload actually received, minus the 3-byte header), floored at 0 for short replies.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
In picolcd_debug_eeprom_read(), before calling copy_to_user(), clamp the copy length to resp->raw_size - 3 (the payload actually received) rather than trusting resp->raw_data[2]; for short replies, floor the computed length at 0.
Linux kernel (hid_picolcd / picolcd_debug_eeprom_read) Clamp length used by copy_to_user to (resp->raw_size - 3) and floor at 0 for short replies = Clamp to resp->raw_size - 3 (payload actually received) before trusting resp->raw_data[2]; if reply is short, use 0
Event History
Frequently Asked Questions
Can this be exploited by an unprivileged local user or remotely?
No. The affected debugfs eeprom file is root-only, and exploitation requires a crafted picoLCD device or a spoofed device returning a malicious REPORT_EE_DATA response.
What can an attacker obtain if exploitation succeeds?
A malicious device can cause the kernel to copy data beyond the 64-byte raw_data buffer into userspace. This may expose adjacent slab memory through the debugfs eeprom file.
Which systems are realistically exposed?
Exposure requires use of the hid_picolcd driver, access to its debugfs eeprom file as root, and interaction with a crafted or spoofed picoLCD device. The issue is not described as remotely or unprivileged-triggerable.