CVE-2026-89620

What it actually does

The Intel QuickSPI HID driver (intel-thc-hid / intel-quickspi) heap-allocates report_buf to the device-descriptor max_report_len (typically a few hundred bytes) but copies a caller-supplied output report in write_cmd_to_txdma() without a length check. The HID core default cap is HID_MAX_BUFFER_SIZE (16384) and this driver does not set max_buffer_size, so a hidraw SET_REPORT or SET_FEATURE request larger than max_report_len overflows the heap buffer with attacker-controlled length and content, corrupting adjacent kernel heap in process context with local privileges.

Why it matters to the business

On Linux hosts that expose Intel QuickSPI HID hardware (typically touch controllers), a logged-in low-privilege user can crash the machine or obtain kernel-level control, which is a full host compromise. The issue is not in CISA KEV, is not associated with ransomware, and has no known public exploit 38 days after publication, so widespread opportunistic attacks are not indicated; CVSS 7.8 with high confidentiality, integrity, and availability impact still makes it urgent on multi-user, VDI, kiosk, and shared workstations until kernels are patched.

How an attack unfolds

An attacker who already has a local account on a Linux system with an Intel QuickSPI HID device opens the corresponding hidraw node and issues a SET_REPORT or SET_FEATURE ioctl whose report is larger than the device’s max_report_len but within the HID core 16 KiB cap. write_cmd_to_txdma() memcpy’s that buffer into the undersized heap allocation (and also writes an output-report header in the same buffer), overflowing kernel heap. The resulting memory corruption can panic the kernel or be abused for local privilege escalation; no named threat actors or in-the-wild campaigns are associated with this CVE.

How to fix it

Apply the upstream Linux kernel fix for HID intel-thc-hid intel-quickspi that records the report_buf allocation size (including the output-report header) and rejects reports that do not fit before copying, matching the intel-quicki2c and hid-goodix-spi guards. Upgrade to a vendor or distribution kernel that includes that commit; no per-package fixed versions were supplied with this record, so follow your distro/kernel vendor advisory. Until patched, restrict write access to hidraw nodes to trusted users/groups via udev and permissions, and blacklist or unload intel-quickspi if the hardware is not required.

How to confirm the fix worked

Confirm the running kernel includes the intel-quickspi report-size check before memcpy in write_cmd_to_txdma() (distribution changelog, kernel CVE tracker, or source/config inspection). Verify intel-quickspi is loaded only where needed (lsmod) and that /dev/hidraw* nodes are not world-writable. After patching, exercise normal HID/touch input and a legitimate hidraw SET_REPORT/SET_FEATURE of valid size to confirm the device still functions; do not send oversized reports as a test.

Typical attack path

1. Obtain a local unprivileged login on a Linux host whose Intel THC QuickSPI HID device is bound to intel-quickspi
2. Identify the matching hidraw node (for example under /dev/hidraw*) that the unprivileged user can open
3. Open the hidraw device and submit a SET_REPORT or SET_FEATURE request whose report length exceeds the device-descriptor max_report_len
4. Trigger the unbounded memcpy in write_cmd_to_txdma() into the heap report_buf
5. Use the resulting kernel heap corruption to cause a denial of service (oops/panic) or escalate to ring 0

How to detect it

There are no reliable network signatures. Look for evidence of local abuse of hidraw on hosts with Intel QuickSPI HID: kernel oops/BUG/panic stacks naming write_cmd_to_txdma, intel-quickspi, or intel-thc-hid; unexpected processes opening /dev/hidraw* and issuing HID SET_REPORT or SET_FEATURE ioctls (audit syscall records for open/ioctl on hidraw); and sudden touch-input driver failures. Correlate with local logins around the time of the oops. Absence of these artifacts does not prove the bug was unused, because a successful heap smash may not leave a distinctive payload string.

• write_cmd_to_txdma
• intel-quickspi
• intel-thc-hid
• /dev/hidraw
• HIDIOCSETREPORT
• HIDIOCSFEATURE

What your security team should do

• Inventory Linux endpoints for Intel THC/QuickSPI HID hardware and a loaded intel-quickspi module, prioritizing multi-user and shared systems
• Patch or upgrade the kernel to a build that includes the intel-quickspi report-size validation; treat as high priority locally even though it is not KEV and has no known exploit
• Until patched, lock down hidraw device node permissions and udev rules so unprivileged users cannot issue SET_REPORT/SET_FEATURE
• Blacklist intel-quickspi on systems that do not need the touch/HID function
• Hunt kernel logs for oops/BUG traces in intel-quickspi or write_cmd_to_txdma and review unexpected hidraw ioctl activity from non-input processes
• Track vendor kernel advisories because this record lists no explicit fixed versions