CVE-2026-80774: Linux Kernel HID Privilege Escalation Flaw

CVE-2026-80774 is a privilege escalation vulnerability in the Linux kernel HID subsystem affecting USB device handling. Attackers can exploit improper interface checks to gain elevated privileges. This article covers technical details, affected versions, impact assessment, and mitigation strategies.

CVE-2026-80774 Overview

CVE-2026-80774 affects the Linux kernel's HID (Human Interface Device) subsystem, specifically the ASUS HID driver. The driver calls to_usb_interface() on a hid_device without first verifying that the device parent is a USB interface. The uhid subsystem can create devices that identify as being on BUS_USB but do not have an actual USB parent, causing the type assumption to fail at runtime.

Critical Impact
A local user with access to /dev/uhid can trigger a kernel splat by registering a spoofed USB-bus HID device, leading to memory safety violations detectable in ASAN kernel builds.

Affected Products

Linux kernel HID subsystem (drivers/hid/hid-asus.c)
Kernel builds exposing uhid device creation to unprivileged or containerized workloads
Stable kernel branches prior to the fixes referenced in the upstream commits

Discovery Timeline

2026-09-04 - CVE-2026-80774 published to NVD
2026-09-04 - Last updated in NVD database

Technical Details for CVE-2026-80774

Vulnerability Analysis

The hid-asus driver uses to_usb_interface(hdev->dev.parent) to obtain the USB interface backing an HID device. The macro assumes the parent device is of type usb_interface and returns a pointer derived from container_of(). When the parent is not a USB interface, the resulting pointer references memory that is not a usb_interface structure. Subsequent dereferences read or write outside the expected object layout.

The uhid userspace interface allows creating HID devices that advertise BUS_USB in their bus identifier without being physically attached to USB. The ASUS driver's probe path matches on vendor and product identifiers alone, so a crafted uhid device can reach the vulnerable code path. Kernel Address Sanitizer (KASAN) builds reliably report the invalid access when the crafted device is enumerated.

Root Cause

The root cause is a missing hid_is_usb(hdev) guard before invoking to_usb_interface(). The hid_is_usb() helper checks whether the parent device is genuinely a USB interface rather than trusting the bus identifier reported by the HID device. Without this check, the driver treats attacker-controlled memory as a usb_interface, which the kernel enforces as an out-of-bounds access in sanitized builds.

Attack Vector

Exploitation requires local access to /dev/uhid, which is typically restricted to privileged users or specific groups. An attacker with that access creates a uhid device advertising ASUS vendor and product identifiers on BUS_USB. When the ASUS HID driver binds, the invalid to_usb_interface() cast triggers the fault. The result is a denial-of-service via kernel splat, with potential for further memory corruption depending on the surrounding code paths. See the upstream fixes at Kernel Git Commit 1ddc2f5 and Kernel Git Commit ee88390 for the corrected logic.

Detection Methods for CVE-2026-80774

Indicators of Compromise

Kernel oops or KASAN reports referencing hid-asus and to_usb_interface in dmesg or /var/log/kern.log
Unexpected loading of the hid_asus module on systems without ASUS hardware
Processes opening /dev/uhid outside of expected applications such as Bluetooth HID daemons

Detection Strategies

Audit for userspace processes issuing UHID_CREATE2 ioctls with ASUS vendor and product identifiers on BUS_USB
Monitor kernel ring buffer for splats matching BUG: or KASAN: alongside hid-asus stack frames
Flag containers or sandboxes that expose /dev/uhid to workloads that do not require virtual HID devices

Monitoring Recommendations

Ship kernel logs to a centralized store and alert on kernel oops or panic events on Linux endpoints
Track loaded kernel modules on production hosts and alert on unexpected driver bind events
Review Linux capability grants for CAP_SYS_ADMIN and access-control lists on /dev/uhid

How to Mitigate CVE-2026-80774

Immediate Actions Required

Apply the upstream stable kernel updates referenced in the commits linked below and reboot affected hosts
Restrict access to /dev/uhid using udev rules or container device cgroups so only trusted daemons can create HID devices
Blacklist the hid_asus module on servers and virtual machines that do not require ASUS peripheral support

Patch Information

The upstream fix adds a hid_is_usb() check before calling to_usb_interface() in hid-asus. Backports are available across stable branches in the following commits: Kernel Git Commit 02bf61d, Kernel Git Commit 1ddc2f5, Kernel Git Commit 8b5deb, Kernel Git Commit bdb2e0a, and Kernel Git Commit ee88390. Consume the kernel package from your distribution once it incorporates these commits.

Workarounds

Remove or tighten permissions on /dev/uhid where virtual HID device creation is not required
Blacklist hid_asus on hosts that never attach ASUS peripherals to prevent driver binding
Restrict container runtimes from mounting the host /dev/uhid node into untrusted workloads

bash

# Configuration example: block the hid_asus module and restrict /dev/uhid
echo 'blacklist hid_asus' | sudo tee /etc/modprobe.d/blacklist-hid-asus.conf
sudo depmod -a

# Restrict /dev/uhid to the input group via udev
printf 'KERNEL=="uhid", MODE="0660", GROUP="input"\n' | \
  sudo tee /etc/udev/rules.d/60-uhid.rules
sudo udevadm control --reload-rules