CVE-2026-31524

What it actually does

This is a Linux kernel denial-of-service flaw in the ASUS HID driver report descriptor fixup path. The vulnerable code allocates a replacement HID report descriptor buffer and returns it without a corresponding free, causing kernel memory to leak when the affected path is exercised. A local attacker with the ability to cause repeated ASUS HID device probing, reconnection, rebinding, or descriptor processing could gradually exhaust kernel memory and degrade or crash the system. The issue also included a minor out-of-bounds read during descriptor copying, but the primary security impact is availability loss rather than data disclosure or integrity compromise.

Why it matters to the business

Successful exploitation can make affected Linux systems unstable or unavailable, potentially causing workstation outages, service interruption, failed jobs, or forced reboots. The risk is lower than remotely exploitable vulnerabilities because exploitation requires local access or control over local HID device interaction, and current public exploitation likelihood is very low based on the provided EPSS score and lack of known exploitation. Systems that allow untrusted users to attach USB/HID devices, use peripheral pass-through, or run shared desktop, lab, kiosk, or virtualized workstation workloads have higher operational exposure.

How an attack unfolds

An attacker first obtains local access to a Linux system or a context where they can influence HID device attachment or driver binding. They then repeatedly trigger the ASUS HID report descriptor fixup path, for example by connecting, disconnecting, rebinding, or emulating a compatible HID device that causes the affected driver logic to run. Each trigger can allocate kernel memory that is not released. By repeating the operation enough times, the attacker consumes available kernel memory, which can lead to memory pressure, OOM-killer activity, degraded performance, failed allocations, driver instability, or a system crash/reboot. The attack does not provide code execution or privilege escalation by itself; its value is disrupting availability.

How to fix it

Upgrade the Linux kernel to a vendor-supported release that includes the upstream fix for the ASUS HID driver memory leak in asus_report_fixup(), which replaces unmanaged allocation with device-managed allocation and corrects descriptor copy length handling. Because no exact fixed package versions were provided, use the fixed kernel versions published by the relevant Linux distribution, hardware vendor, or appliance vendor. Where immediate patching is not possible, reduce exposure by restricting physical access to USB/HID ports, disabling unneeded USB/HID pass-through in virtualization or remote desktop environments, limiting local shell access to trusted users, and monitoring for repeated HID device attach/detach or driver bind/unbind activity. Avoid unsupported custom kernels unless the upstream patch has been backported and verified.

How to confirm the fix worked

Confirm exposure by checking whether systems run an affected Linux kernel build and whether the ASUS HID driver is present or loadable. Validate remediation by confirming the installed kernel package includes the vendor fix, rebooting into the fixed kernel, and verifying the running kernel version with standard OS inventory tooling. On Linux hosts, review loaded modules and driver activity using commands such as uname -a, package-manager kernel version queries, lsmod, modinfo hid_asus, and dmesg or journalctl kernel logs. In test environments, repeated HID device re-probing should no longer produce sustained unreclaimed kernel memory growth attributable to the ASUS HID fixup path. Also confirm that older vulnerable kernels are not still bootable by default from the bootloader.

Typical attack path

1. Gain local access to an affected Linux system or to a path that can influence local HID device enumeration, such as physical peripheral access or USB/HID pass-through.
2. Identify that the system loads the ASUS HID driver path for a compatible HID device or descriptor.
3. Repeatedly trigger HID probe/report-fixup handling through device connect/disconnect, driver unbind/rebind, or compatible device emulation.
4. Cause unreleased kernel allocations to accumulate over time.
5. Drive the system into memory pressure, OOM-killer activity, degraded service, or crash, resulting in denial of service.

How to detect it

To determine whether exploitation or attempted exploitation already occurred, review kernel and system logs for unusual bursts of HID or USB device enumeration involving ASUS HID devices, repeated driver bind/unbind activity, and memory pressure shortly afterward. Relevant sources include journalctl -k, dmesg, /var/log/kern.log, /var/log/messages, /var/log/syslog, auditd logs if driver sysfs access is audited, udev logs, endpoint telemetry, and hypervisor logs for USB/HID pass-through events. Look for repeated attach/detach cycles, hid-asus probe activity, OOM-killer events, page allocation failures, sudden memory exhaustion, unexplained service terminations, or reboots. There are no known public threat actors or campaigns associated with this issue in the provided data, so detection should focus on behavioral signs of local denial-of-service activity rather than malware-specific artifacts.

• hid-asus
• asus_report_fixup
• ASUS HID
• HID: asus
• page allocation failure
• Out of memory: Killed process
• oom-killer
• invoked oom-killer
• Memory allocation failure
• usb disconnect
• new full-speed USB device
• new high-speed USB device
• hid-generic
• /sys/bus/hid/drivers
• /sys/bus/usb/drivers
• /sys/bus/hid/drivers/hid-asus/unbind
• /sys/bus/hid/drivers/hid-asus/bind

What your security team should do

• Prioritize patching shared Linux workstations, lab systems, kiosks, VDI hosts, build machines, and virtualization platforms where untrusted users may have local access or USB/HID pass-through.
• Inventory Linux systems for affected kernel versions and presence of the ASUS HID driver or ASUS HID-compatible peripherals.
• Apply distribution or vendor kernel updates that include the fix, then reboot to ensure the fixed kernel is running.
• Restrict physical and logical access to USB/HID device attachment paths until patching is complete.
• Disable unnecessary USB pass-through, peripheral redirection, or driver rebinding capabilities for untrusted users.
• Monitor kernel logs for repeated HID attach/detach events, hid-asus activity, memory allocation failures, OOM-killer events, or unexplained local system instability.
• Because the vulnerability is not in CISA KEV, has no known exploit maturity, and has very low EPSS, treat it as a hygiene and availability patch unless the environment permits untrusted local device interaction.