CVE-2026-53037

What it actually does

This is a Linux kernel denial-of-service flaw in the USB HID reset path. A specially crafted composite USB device that exposes both a HID interface and a storage/UAS interface can force reset handling where HID pre-reset/post-reset code performs memory allocation in a context that must not trigger block I/O. If allocation enters reclaim or I/O while block-layer error handling is holding reset-related locks, the kernel can deadlock, leaving I/O, USB reset handling, or affected kernel threads stuck and potentially causing a system hang or requiring reboot.

Why it matters to the business

Systems that accept untrusted USB peripherals can be made unstable or unavailable by a malicious or malformed USB device. The practical risk is highest for laptops, workstations, kiosks, point-of-sale systems, lab equipment, industrial operator stations, and servers with exposed USB ports. Although there is no known public exploitation or CISA KEV listing and the EPSS score is very low, the impact can still be operationally significant where local physical access, supply-chain peripheral risk, or shared-device environments are realistic.

How an attack unfolds

An attacker needs the ability to connect or cause the target to connect to a crafted USB device. The device presents itself as a composite USB peripheral containing both a HID component, such as keyboard-like functionality, and a mass-storage or UAS component. The attacker then triggers storage or USB error conditions that cause the kernel to reset the combined device. During reset, the HID driver reset callbacks run while block I/O error handling holds locks. In vulnerable kernels, memory allocation in this path can attempt block I/O, creating a circular wait and deadlocking the reset path. The result is denial of service: hung kernel tasks, stalled storage I/O, an unresponsive USB subsystem, or a system that requires administrative intervention or reboot.

How to fix it

Apply a Linux kernel update that includes the HID usbhid fix changing reset-path allocations to GFP_NOIO in hid_pre_reset() and hid_post_reset(). Because no product-specific fixed versions were provided, use the fixed kernel packages from the relevant Linux distribution, appliance vendor, or upstream stable kernel branch. Reboot into the updated kernel after installation. Where immediate patching is not possible, reduce exposure by restricting physical USB access, disabling unused USB ports in firmware or operating-system policy, blocking USB mass-storage/UAS where not required, enforcing USB device allowlisting, and avoiding use of untrusted composite USB devices.

How to confirm the fix worked

Confirm the running kernel is a vendor-fixed build, not merely that a package is installed. Validate with the distribution advisory or upstream stable changelog showing the usbhid reset GFP_NOIO fix. On Linux systems, compare `uname -r` against the vendor-fixed kernel version and verify the installed kernel package changelog references the HID usbhid deadlock fix. For exposure validation, identify systems that allow physical USB device attachment and have USB HID plus usb-storage or UAS drivers available. Avoid testing with intentionally malicious USB devices on production systems because validation can hang the host.

Typical attack path

1. Obtain physical, supply-chain, or peripheral-access opportunity to a Linux system with USB enabled.
2. Connect a malicious composite USB device exposing HID plus USB storage or UAS interfaces.
3. Induce storage/UAS errors or reset conditions on the composite device.
4. Trigger the vulnerable HID reset path during block I/O error handling.
5. Cause a kernel deadlock that stalls I/O, USB reset processing, or broader system responsiveness.
6. Maintain denial of service until the device is removed, the affected subsystem recovers, or the host is rebooted.

How to detect it

Post-exploitation evidence is most likely in kernel logs, system journals, endpoint telemetry, and physical/device-control records rather than in application logs. Review `dmesg`, `/var/log/kern.log`, `/var/log/messages`, and `journalctl -k` for USB composite device attachment followed by storage/UAS errors, USB resets, HID reset activity, hung task warnings, blocked kernel threads, or I/O stalls. Correlate these events with endpoint device-control logs showing new USB devices that enumerate as both HID and mass storage/UAS. Look for timelines where a USB device was inserted shortly before system unresponsiveness, storage timeout messages, or watchdog/hung-task reports. If a system required a hard reboot after USB insertion, preserve volatile logs where possible and collect USB descriptors from the suspected device in an isolated forensic environment.

• hid_post_reset
• hid_pre_reset
• usbhid
• usb-storage
• uas
• reset SuperSpeed USB device
• reset high-speed USB device
• USB Mass Storage device detected
• new full-speed USB device
• new high-speed USB device
• new SuperSpeed USB device
• task blocked for more than
• blocked for more than 120 seconds
• INFO: task
• hung_task_timeout_secs
• I/O error, dev sd
• Buffer I/O error on dev
• uas_eh_abort_handler
• uas_eh_device_reset_handler
• usb_reset_device

What your security team should do

• Prioritize patching systems with exposed or user-accessible USB ports, including kiosks, shared workstations, POS terminals, lab systems, and operational technology workstations.
• Deploy the vendor-fixed kernel and reboot systems into the patched version; confirm the running kernel after reboot.
• Temporarily restrict untrusted USB peripheral use until patching is complete.
• Disable or block USB mass-storage and UAS drivers where business processes do not require them.
• Use endpoint/device-control tooling to allowlist approved USB devices and alert on new composite HID plus storage devices.
• Review kernel and system logs for unexplained USB resets, hung tasks, blocked I/O, or system hangs following USB device insertion.
• Update incident response playbooks for suspected malicious USB events to include preservation of kernel logs and collection of attached USB device descriptors.