{
  "affected": [
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:12",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:13",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:14",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "details": "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-\u003eraw_data[2] -- a length byte supplied by the device in its REPORT_EE_DATA reply -- clamped only to the caller's read() count:  \tret = resp-\u003eraw_data[2]; \tif (ret \u003e s) \t\tret = s; \tif (copy_to_user(u, resp-\u003eraw_data+3, ret))  It never checks resp-\u003eraw_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 \u003e= 255, makes copy_to_user() read past raw_data[] into adjacent slab memory and return it to userspace through the debugfs \"eeprom\" file:  \tBUG: KASAN: slab-out-of-bounds in _copy_to_user \tRead 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-\u003eraw_size - 3 (the payload actually received, minus the 3-byte header), floored at 0 for short replies.",
  "id": "DEBIAN-CVE-2026-89628",
  "modified": "2026-09-12T08:47:20.064927819Z",
  "published": "2026-09-11T20:19:48.270Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://security-tracker.debian.org/tracker/CVE-2026-89628"
    }
  ],
  "upstream": [
    "CVE-2026-89628"
  ]
}