Description
In the Linux kernel, the following vulnerability has been resolved:

HID: picolcd: clamp eeprom debugfs read to bytes actually received

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.
Published: 2026-09-11
Score: 5.4 Medium
EPSS: < 1% Very Low
KEV: No
Impact: Kernel memory disclosure
Action: Apply patch
AI Analysis

Impact

In Linux kernel versions that include the hid_picolcd driver, the eeprom debugfs read path trusts a length byte supplied by the pico data actually received. This represents a CWE-805: Buffer Copy without Checking Size vulnerability. The driver copies this potentially oversized value into a user buffer and then performs a copy_to_user of that many bytes. If the device reports a length of 0xff and the read count is at least 255,‑byte buffer, causing a kernel memory leak. Because the debugfs file is owned with root‑only permissions, privileged user and does not provide a privilege escalation path.

Affected Systems

Any Linux kernel release that shipped the vulnerable hid_picolcd driver before the fix is affected. The vendor is enumerated, so any kernel containing the unpatched driver may be compromised.

Risk and Exploitability

The CVSS score of 5.4 reflects a medium‑severity local exploitation scenario. The EPSS score of < 1% indicates a very low probability of exploitation, and the vulnerability is not listed in the CISA KEV catalog. An attacker must already have root and supply a fabricated length byte. Under these stringent conditions, the kernel will leak contiguous slab memory through the debugfs file that only root can read. The consequence is limited to information disclosure for an already‑privileged user and does not grant remote access or privilege escalation.

Generated by OpenCVE AI on September 13, 2026 at 05:28 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Update the kernel to a version containing the picoLCD driver patch
  • Reboot the system after installing the patched kernel to ensure the vulnerable driver is unloaded
  • Verify that the eeprom debugfs file remains root‑only; if its permissions are broader, reset them to 0400

Generated by OpenCVE AI on September 13, 2026 at 05:28 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Sat, 12 Sep 2026 00:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-805
References
Metrics threat_severity

None

cvssV3_1

{'score': 5.4, 'vector': 'CVSS:3.1/AV:P/AC:H/PR:H/UI:N/S:U/C:H/I:N/A:H'}

threat_severity

Moderate


Fri, 11 Sep 2026 23:45:00 +0000

Type Values Removed Values Added
Description In the Linux kernel, the following vulnerability has been resolved: HID: picolcd: clamp eeprom debugfs read to bytes actually received 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.
Title HID: picolcd: clamp eeprom debugfs read to bytes actually received
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-09-11T19:45:24.203Z

Reserved: 2026-09-11T19:38:34.738Z

Link: CVE-2026-89628

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-09-11T20:19:48.270

Modified: 2026-09-11T20:19:48.270

Link: CVE-2026-89628

cve-icon Redhat

Severity : Moderate

Publid Date: 2026-09-11T19:45:24Z

Links: CVE-2026-89628 - Bugzilla

cve-icon OpenCVE Enrichment

Updated: 2026-09-13T05:30:06Z

Weaknesses
  • CWE-805

    Buffer Access with Incorrect Length Value