MEDIUM 5.5

CVE-2026-53037: Linux Kernel HID USB Deadlock Vulnerability – Local DoS Risk

A deadlock vulnerability exists in the Linux kernel's USB HID (Human Interface Device) driver reset handling. When a USB device combines HID functionality with storage or UAS (USB Attached SCSI) components, the kernel must reset all components together. The vulnerability occurs because memory allocation during the reset process can trigger block I/O operations, which deadlock against a mutex held during device reset. This causes the system to hang when such hybrid USB devices encounter errors requiring reset.

Source data · NVD / CISA · public domain

CVSS
3.1 · 5.5 MEDIUM · CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Weaknesses (CWE)
CWE-667
Affected products
1 configuration(s)
Published / Modified
2026-06-24 / 2026-07-14

NVD description (verbatim)

In the Linux kernel, the following vulnerability has been resolved: HID: usbhid: fix deadlock in hid_post_reset() You can build a USB device that includes a HID component and a storage or UAS component. The components can be reset only together. That means that hid_pre_reset() and hid_post_reset() are in the block IO error handling. Hence no memory allocation used in them may do block IO because the IO can deadlock on the mutex held while resetting a device and calling the interface drivers. Use GFP_NOIO for all allocations in them.

8 reference(s) · View on NVD →

SEC.co analysis · AI-assisted, reviewed against source

Technical summary

CVE-2026-53037 is a deadlock condition in the Linux kernel's HID subsystem, specifically in the hid_pre_reset() and hid_post_reset() functions within the usbhid driver. The issue arises from incorrect memory allocation flags during USB device reset operations. When USB devices with both HID and block storage interfaces (storage or UAS) experience errors, the kernel invokes reset handlers that hold a mutex. If these handlers perform memory allocations using default flags (GFP_KERNEL), the allocator may trigger block I/O to satisfy the request. This block I/O attempt blocks on the same mutex already held by the reset handler, creating a classic deadlock scenario. The fix involves replacing standard allocation flags with GFP_NOIO to prevent memory allocations from initiating block I/O operations during reset sequences.

Business impact

System availability is the primary concern. A deadlock in device reset handling can freeze the entire system or make it unresponsive when combined USB devices (such as external drives with input device components) experience transient errors. This affects workstations, servers, and embedded systems using such hybrid USB peripherals. Users may lose work, services may become unavailable, and recovery requires hard reboots. The impact is localized to systems with specific USB device configurations but can be severe for affected deployments.

Affected systems

The vulnerability affects the Linux kernel across all versions prior to patching. Impact is specific to systems that: (1) use USB devices combining HID functionality with storage or UAS interfaces, (2) encounter USB error conditions requiring device reset, and (3) have memory pressure conditions where allocation might trigger I/O. This includes desktop workstations with external drives featuring built-in input devices (e.g., keyboard+storage combos), servers with attached peripherals, and any embedded Linux system using such devices. The vulnerability does not affect systems using HID-only or storage-only USB devices exclusively.

Exploitability

Exploitability requires specific hardware configuration (hybrid USB devices) and error conditions that trigger reset handlers—both largely outside attacker control in typical scenarios. However, a local authenticated attacker with access to a system could potentially force USB device resets through sysfs interfaces or by triggering error conditions on attached devices, making the system unresponsive. The attack requires local access and specific hardware, making it lower-risk than remote exploits but still meaningful for multi-user systems or those where attackers have physical or local network access.

Remediation

Update to a patched Linux kernel version that applies GFP_NOIO allocation flags to hid_pre_reset() and hid_post_reset(). Verify the specific kernel version containing this fix by consulting your distribution's security advisory. As an interim mitigation, disconnect or avoid using hybrid USB devices (devices combining HID with storage/UAS) where possible, or ensure USB hub or device firmware is current to reduce error conditions that trigger resets. Systems using HID-only or storage-only USB devices are not vulnerable.

Patch guidance

Kernel maintainers and distributions will provide patched kernel versions. Update your Linux distribution's kernel package to the version specified in the relevant security advisory—verify the patch commit hash (which modifies memory allocation flags in usbhid driver reset handlers) is included. Testing should include hybrid USB device attachment and error simulation to confirm the deadlock no longer occurs. Reboot is required after kernel update.

Detection guidance

Monitor system logs for: (1) hung task warnings or soft lockup messages mentioning hid or usbhid subsystems, (2) reset handler traces involving hid_pre_reset or hid_post_reset, (3) system hangs correlating with USB device error events or reset attempts. On affected systems, kernel trace events (CONFIG_TRACE_EVENTS enabled) can log entry/exit of reset functions. Live system analysis via crash dumps can show mutex contention on hid reset paths. Detection is reactive (hang must occur); prevention via patching is the primary control.

Why prioritize this

MEDIUM severity (CVSS 5.5) reflecting local-only attack surface and availability impact without confidentiality or integrity compromise. Prioritize patching based on: (1) presence of hybrid USB devices in your environment, (2) criticality of affected systems, (3) frequency of USB error conditions (which vary by infrastructure). High-volume desktop or laptop deployments using external drives should prioritize sooner; servers or systems using HID-only or storage-only USB exclusively can defer slightly, though kernel updates should follow routine patching cadence.

Risk score, explained

The CVSS:3.1 score of 5.5 (MEDIUM) reflects: AV:L (attack vector local—requires system access), AC:L (attack complexity low—error conditions can occur naturally or be forced), PR:L (privilege required—local user level sufficient), UI:N (no user interaction needed), S:U (scope unchanged), C:N/I:N/A:H (high availability impact via denial of service through deadlock, no confidentiality or integrity loss). The score appropriately weights a denial-of-service vulnerability with local prerequisites.

Frequently asked questions

Do I need to patch if I only use HID devices like keyboards and mice?

No. The vulnerability requires USB devices combining HID with storage or UAS interfaces. HID-only devices (keyboards, mice, gamepads) are not affected because the reset handlers' deadlock condition only manifests when block storage reset logic is involved.

Can this be exploited remotely?

No. The vulnerability requires local access to trigger USB device resets or errors. Remote exploitation is not feasible. However, any local user or attacker with physical access to USB ports can potentially trigger the condition.

Will this cause data loss?

Not directly. The vulnerability causes system hangs via deadlock, requiring hard reboot. Data loss risk depends on filesystem state at the time of hang and recovery. Mitigation focuses on system availability restoration, not data protection.

What if my Linux distribution hasn't released a patched kernel yet?

Check your distribution's security advisories for timeline. If a patch is not yet available, mitigate by avoiding use of hybrid USB devices if possible, keeping device firmware updated, and monitoring for unusual USB reset errors. Follow your distribution's kernel update schedule closely once available.

This analysis is based on publicly available vulnerability data as of the publication date and represents the current understanding of CVE-2026-53037. Specific patch versions and affected kernel releases should be verified against official Linux kernel security advisories and your distribution's security updates. Testing recommendations assume standard kernel build configurations; custom kernels or embedded distributions may require additional validation. This vulnerability requires specific hardware configurations and error conditions; the actual risk in any given environment depends on device inventory and usage patterns. Always test kernel updates in non-production environments before deployment. SEC.co does not provide warranty or liability coverage for patching decisions or system configurations based on this analysis. Source: NVD (public-domain), retrieved 2026-07-31. Analysis generated by SEC.co (claude-haiku-4-5).