CVE-2026-64367

What it actually does

This is a local Linux kernel stack buffer overflow in the Goodix SPI HID driver. The vulnerable function builds an outbound HID protocol frame in a fixed 128-byte stack buffer, then copies caller-controlled report data into that buffer without validating whether the header plus payload fits. A local user with access to an affected hidraw device can issue a SET_REPORT ioctl with an oversized report, corrupting kernel stack memory. Depending on kernel hardening, hardware state, and exploit reliability, this can cause a kernel crash or potentially enable local privilege escalation with kernel-level code execution.

Why it matters to the business

Systems using affected Linux kernels with the Goodix SPI HID driver exposed to local users may be vulnerable to denial of service or privilege escalation. In practical terms, a user or process that already has local access could crash the machine or potentially gain full control of it, affecting workstation stability, kiosk/tablet devices, embedded Linux devices, and shared systems where hidraw access is available. The issue is not listed in CISA KEV, has low EPSS, and has no known public exploit maturity in the provided data, so internet-scale exploitation is unlikely; however, kernel privilege-escalation bugs should still be prioritized where untrusted users, sandboxed workloads, or physical-access scenarios exist.

How an attack unfolds

An attacker first obtains local code execution or an interactive session on a Linux system that uses the vulnerable Goodix SPI HID driver. They then identify an accessible hidraw node associated with the Goodix HID device, commonly under /dev/hidraw*. If permissions allow the attacker-controlled process to open the device, the attacker sends a crafted HID SET_REPORT request with a payload larger than the driver's stack buffer can safely hold after the protocol header is added. The vulnerable driver copies the oversized report into a 128-byte stack buffer, overwriting adjacent kernel stack data. A failed attempt may produce a kernel oops, panic, KASAN report, or stack protector failure. A successful exploit may manipulate corrupted kernel control data to escalate privileges or execute code in kernel context.

How to fix it

Upgrade to a Linux kernel version or vendor kernel package that includes the hid-goodix-spi bounds-checking fix for goodix_hid_set_raw_report(). Because no exact fixed package versions were provided, use the applicable distribution, device vendor, or upstream stable kernel advisory to identify the first fixed build for each supported kernel stream. Where immediate patching is not possible, reduce exposure by restricting access to /dev/hidraw* devices to trusted users only, reviewing udev rules that grant broad hidraw permissions, disabling or blacklisting the hid-goodix-spi driver where the hardware is not required, and limiting local code execution on affected endpoints. Kernel hardening features such as stack protector, KASAN in test builds, lockdown, module signing, and strict device permissions can reduce exploitability but should not be treated as complete fixes.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel package includes the vendor fix, not just that an updated package is installed on disk. Check the active kernel version with uname -a and compare it to the vendor's fixed release notes or changelog for the hid-goodix-spi report-size validation patch. On source-based or custom kernels, confirm the driver rejects SET_REPORT requests whose constructed frame would exceed the 128-byte temporary buffer. Validate exposure by checking whether the hid-goodix-spi module is loaded or built in, whether Goodix SPI HID hardware is present, and whether untrusted users can access /dev/hidraw* device nodes. A negative validation result is expected when the driver is absent, the hardware path is unavailable, or hidraw access is restricted to trusted administrative contexts.

Typical attack path

1. Gain local execution on an affected Linux system, such as through a low-privileged shell, compromised user account, malicious local application, or sandbox escape attempt.
2. Determine whether the Goodix SPI HID driver is present and whether a hidraw device node is accessible to the attacker.
3. Open the relevant /dev/hidraw* device with sufficient permissions.
4. Issue a crafted HID SET_REPORT ioctl containing report data larger than the driver's fixed stack buffer can accommodate.
5. Trigger stack corruption in the kernel driver during memcpy of the report payload.
6. Cause a denial-of-service crash or attempt to shape the stack corruption into local privilege escalation.

How to detect it

Post-exploitation detection is difficult because exploitation occurs locally through a device ioctl and may not leave network indicators. Use kernel logs, audit logs, endpoint telemetry, and crash dumps. Review dmesg, journald, /var/log/kern.log, /var/log/messages, and crash/pstore records for kernel oopses, panics, stack protector failures, or KASAN reports involving hid-goodix-spi or goodix_hid_set_raw_report. If Linux auditd or EDR is available, search for unexpected processes opening /dev/hidraw* and issuing ioctls, especially processes running from temporary directories, user-writable paths, or unknown binaries. Correlate hidraw access with privilege changes, new root-owned files, setuid file creation, suspicious kernel crashes, or reboots. Because this vulnerability requires local access, also review authentication logs and endpoint process history around the time of any kernel crash. There are no public exploit-specific byte patterns in the provided data, so detection should focus on vulnerable-driver crash artifacts and anomalous hidraw device access.

• goodix_hid_set_raw_report
• hid-goodix-spi
• KASAN: stack-out-of-bounds
• KASAN: slab-out-of-bounds
• stack smashing detected
• kernel BUG
• Oops:
• general protection fault
• Kernel panic
• /dev/hidraw
• SET_REPORT
• hidraw

What your security team should do

• Inventory Linux endpoints and embedded systems for affected kernels using the Goodix SPI HID driver, prioritizing systems with untrusted local users, shared access, kiosk use, or physical exposure.
• Patch affected systems to a vendor kernel release that includes the hid-goodix-spi report-size validation fix.
• Audit /dev/hidraw* permissions and udev rules; remove broad access grants such as world-writable hidraw devices or unnecessary membership in device-access groups.
• If the hardware is not needed, disable or blacklist the hid-goodix-spi driver as a temporary mitigation.
• Monitor kernel logs for crashes or memory-corruption reports referencing hid-goodix-spi, goodix_hid_set_raw_report, KASAN, stack smashing, or kernel oops events.
• Treat suspicious local access to hidraw devices by unexpected processes as potential exploitation activity, especially when followed by kernel instability or privilege changes.
• For custom kernel builds, backport the bounds check and rebuild, then confirm the running kernel is the patched image after reboot.