CVE-2026-89619

What it actually does

The Linux kernel Intel QuickSPI HID driver (intel-thc-hid) copies a device-supplied GET_REPORT payload into the caller buffer without enforcing the caller-provided length. quickspi_hid_raw_request() receives the requested length, but quickspi_get_report() memcpy()s qsdev->report_len bytes of touch-controller data into buf regardless, overflowing a kernel buffer with device-controlled content. This is a local kernel memory-corruption primitive (buffer overflow) affecting confidentiality, integrity, and availability of kernel memory, with potential for privilege escalation, arbitrary kernel read/write, or denial of service. The intel-quicki2c sibling already validated length before copy; this path did not.

Why it matters to the business

Hosts with Intel Touch Host Controller QuickSPI HID hardware can be crashed or fully compromised by a local low-privilege user or a malicious/compromised HID peripheral, leading to host takeover, data exposure, and outage. CVSS 7.8 (AV:L/AC:L/PR:L/UI:N, C/I/A High) reflects full-impact local kernel compromise. The issue is not in CISA KEV, is not associated with ransomware campaigns, and has no known public exploit maturity about 38 days after publication (2026-09-11), so mass opportunistic risk is currently lower than for KEV kernel bugs—but any Linux fleet using this driver should still treat it as a high-priority kernel patch because a single local foothold or hostile HID device can own the machine.

How an attack unfolds

An attacker with local access on a Linux system where the intel-quickspi driver is loaded, or who can present a malicious report on the QuickSPI touch path, triggers a HID GET_REPORT (typically via hidraw HIDIOCGFEATURE or HIDIOCGINPUT). The controller returns a report whose length exceeds the buffer the caller allocated. The driver copies the full device-controlled response, overflowing kernel memory. Corrupted adjacent kernel objects can then be abused to escalate from an unprivileged local process (or from device-controlled input) to kernel-equivalent privileges, install persistence, or panic the host. No named threat actors or in-the-wild campaigns are associated with this CVE at publication-plus-38-days, and exploit maturity is none, so observed activity would be noteworthy.

How to fix it

Apply the upstream Linux kernel fix for HID intel-thc-hid intel-quickspi that passes the caller length into quickspi_get_report() and rejects or truncates responses larger than the destination buffer before memcpy (mirroring intel-quicki2c). Upgrade to a distribution kernel that includes this HID intel-quickspi GET_REPORT bounds check; exact package versions were not supplied with this record, so use vendor/distro security advisories and git/stable commit history for HID: intel-thc-hid: intel-quickspi. Until patched, restrict unprivileged access to hidraw nodes for Intel THC/QuickSPI devices (udev/ACL/group membership), limit who can load or talk to the driver, and avoid untrusted HID peripherals on affected hardware. Reboot into the patched kernel to make the fix active.

How to confirm the fix worked

Confirm the running kernel includes the intel-quickspi GET_REPORT length check (caller len passed through and compared to qsdev->report_len before copy). Inspect kernel source or distro changelog for the intel-quickspi bounds fix; verify intel-thc-hid/intel-quickspi is present only if hardware requires it (lsmod, /sys/bus/hid, dmesg). After upgrade, reboot and confirm the new kernel uname and package changelog. On still-vulnerable kernels, hidraw GET_REPORT against the QuickSPI device with a small user buffer is the exposure condition—do not use that as a crash test in production. Inventory systems with Intel THC QuickSPI touch hardware as in-scope.

Typical attack path

1. Gain local unprivileged execution on a Linux host that loads the intel-quickspi/intel-thc-hid driver, or attach/compromise a HID device on the Intel QuickSPI touch path.
2. Open the corresponding hidraw interface and issue a GET_REPORT-style request (HIDIOCGFEATURE or HIDIOCGINPUT) with a caller buffer shorter than the device-supplied report.
3. Cause the touch controller (or emulated report path) to return a report_len larger than that buffer so the unbounded memcpy overwrites kernel memory with attacker-influenced bytes.
4. Turn the resulting kernel corruption into elevated privileges, kernel code execution, or a host crash.
5. Abuse kernel-level control for persistence, credential or secret access, or further movement on the host.

How to detect it

There is no public exploit and no KEV/ransomware association, so hunting is for kernel memory-corruption symptoms on intel-quickspi hosts rather than a known payload. Review kernel logs (dmesg, journalctl -k, /var/log/kern.log, pstore/kmsg) around hidraw GET_REPORT activity for oops, panic, KASAN slab-out-of-bounds, or use-after-free with RIP/backtrace in intel-quickspi, quickspi_get_report, quickspi_hid_raw_request, intel-thc-hid, or hid-core. Audit auditd/syscall logs for unexpected open/ioctl on /dev/hidraw* by unprivileged users, especially HID feature/input report ioctls. On crash dumps, look for corrupted heap objects adjacent to HID report buffers and device-supplied report_len larger than the hidraw request. Recurring touch-controller disconnects plus kernel faults on the same host are worth correlating. Absence of these artifacts does not prove the bug was unused; it only means no noisy crash was recorded.

• intel-quickspi
• quickspi_get_report
• quickspi_hid_raw_request
• intel-thc-hid
• HIDIOCGFEATURE
• HIDIOCGINPUT
• /dev/hidraw
• BUG: KASAN: slab-out-of-bounds
• Unable to handle kernel
• Call Trace:.*quickspi

What your security team should do

• Patch and reboot Linux systems that load intel-quickspi/intel-thc-hid as soon as distro kernels with the GET_REPORT bounds check are available; do not wait for KEV listing.
• Inventory hosts with Intel Touch Host Controller / QuickSPI HID (driver, DMI, hidraw) so remediation is scoped to real exposure rather than every Linux box.
• Until patched, lock down /dev/hidraw* permissions and unprivileged HID ioctl access for these devices, and treat unexpected HID peripherals as untrusted.
• Watch kernel logs for oops/KASAN/panic frames in intel-quickspi or hid-core around GET_REPORT; investigate as potential exploitation or instability.
• Track distro advisories for this HID fix and confirm backup/recovery for laptops and kiosks that depend on the touch controller.