Re: [PATCH] HID: picolcd: clamp eeprom debugfs read to bytes actually received

Jiri Kosina <[email protected]>
Newsgroups org.kernel.vger.linux-kernel,org.kernel.vger.linux-input,org.kernel.vger.stable
Message-ID <[email protected]>
On Wed, 15 Jul 2026, Ibrahim Hashimov wrote:

> picolcd_debug_eeprom_read() trusts resp->raw_data[2] -- a length byte
> supplied by the device in its REPORT_EE_DATA reply -- clamped only to
> the caller's read() count:
> 
> 	ret = resp->raw_data[2];
> 	if (ret > s)
> 		ret = s;
> 	if (copy_to_user(u, resp->raw_data+3, ret))
> 
> It never checks resp->raw_size, the number of bytes picolcd_raw_event()
> actually copied into the 64-byte raw_data[] of the kmalloc'd struct
> picolcd_pending. A device (or a spoofed picoLCD) returning a length byte
> of 0xff, read with a count >= 255, makes copy_to_user() read past
> raw_data[] into adjacent slab memory and return it to userspace through
> the debugfs "eeprom" file:
> 
> 	BUG: KASAN: slab-out-of-bounds in _copy_to_user
> 	Read of size 255 ... picolcd_debug_eeprom_read+0x214/0x2f0 [hid_picolcd]
> 
> 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 S_IRUSR (root-only) and a crafted device is needed,
> so it is neither unprivileged- nor remotely-triggerable.
> 
> Clamp the copy length to resp->raw_size - 3 (the payload actually
> received, minus the 3-byte header), floored at 0 for short replies.
> 
> Fixes: 9bbf2b98ba11 ("HID: add experimental access to PicoLCD device's EEPROM and FLASH")
> Cc: [email protected]
> Signed-off-by: Ibrahim Hashimov <[email protected]>
> Assisted-by: AuditCode-AI:2026.07

Applied, thanks.

-- 
Jiri Kosina
SUSE Labs
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.