{"id":"AZL-100241","summary":"CVE-2026-89628 affecting package kernel 6.6.150.1-1","details":"In the Linux kernel, the following vulnerability has been resolved:\n\nHID: picolcd: clamp eeprom debugfs read to bytes actually received\n\npicolcd_debug_eeprom_read() trusts resp-\u003eraw_data[2] -- a length byte\nsupplied by the device in its REPORT_EE_DATA reply -- clamped only to\nthe caller's read() count:\n\n\tret = resp-\u003eraw_data[2];\n\tif (ret \u003e s)\n\t\tret = s;\n\tif (copy_to_user(u, resp-\u003eraw_data+3, ret))\n\nIt never checks resp-\u003eraw_size, the number of bytes picolcd_raw_event()\nactually copied into the 64-byte raw_data[] of the kmalloc'd struct\npicolcd_pending. A device (or a spoofed picoLCD) returning a length byte\nof 0xff, read with a count \u003e= 255, makes copy_to_user() read past\nraw_data[] into adjacent slab memory and return it to userspace through\nthe debugfs \"eeprom\" file:\n\n\tBUG: KASAN: slab-out-of-bounds in _copy_to_user\n\tRead of size 255 ... picolcd_debug_eeprom_read+0x214/0x2f0 [hid_picolcd]\n\nThe debug-dump path in the same file already validates the device length\nbyte against the received size before trusting it; this read does not.\nThe file is created S_IRUSR (root-only) and a crafted device is needed,\nso it is neither unprivileged- nor remotely-triggerable.\n\nClamp the copy length to resp-\u003eraw_size - 3 (the payload actually\nreceived, minus the 3-byte header), floored at 0 for short replies.","modified":"2026-09-13T06:06:36Z","published":"2026-09-11T20:19:48Z","upstream":["CVE-2026-89628"],"references":[{"type":"WEB","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-89628"}],"affected":[{"package":{"name":"kernel","ecosystem":"Azure Linux:3","purl":"pkg:rpm/azure-linux/kernel"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"last_affected":"6.6.150.1-1"}]}],"database_specific":{"source":"https://github.com/microsoft/AzureLinuxVulnerabilityData/blob/main/osv/AZL-100241.json"}}],"schema_version":"1.9.0"}