Skip to main content

Linux Kernel EUVDEUVD-2026-38905

| CVE-2026-53037 MEDIUM
Improper Locking (CWE-667)
2026-06-24 Linux GHSA-v8qx-g69v-pph9
5.5
CVSS 3.1 · NVD
Share

Severity by source

NVD PRIMARY
5.5 MEDIUM
AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
vuln.today AI
4.7 MEDIUM

AV:L and PR:L confirmed by description; AC:H reflects the non-default hardware prerequisite (composite USB HID+storage device required); C:N and I:N per description.

3.1 AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
4.0 AV:L/AC:H/AT:P/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
SUSE
4.6 MEDIUM
AV:P/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Red Hat
5.5 LOW
qualitative

Primary rating from NVD.

CVSS VectorNVD

Attack Vector
Local
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
High

Lifecycle Timeline

5
Analysis Generated
Jul 22, 2026 - 20:49 vuln.today
CVSS changed
Jul 14, 2026 - 19:52 NVD
5.5 (MEDIUM)
Patch available
Jun 24, 2026 - 18:02 EUVD
CVE Published
Jun 24, 2026 - 16:29 nvd
MEDIUM 5.5
CVE Published
Jun 24, 2026 - 16:29 cve.org
UNKNOWN (no severity yet)

DescriptionNVD

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.

AnalysisAI

Deadlock in the Linux kernel's usbhid driver (hid_post_reset()) can halt systems connected to composite USB devices that combine HID and block storage or UAS components. When such a device undergoes a reset during block IO error handling, memory allocations using the default GFP_KERNEL flag can trigger block IO reclaim, which deadlocks against the mutex already held by the reset path - producing a kernel hang. No public exploit has been identified, and EPSS of 0.18% (7th percentile) confirms very low exploitation likelihood; the fix replaces GFP_KERNEL with GFP_NOIO across all affected reset callbacks, and patches are available across multiple Linux stable branches.

Technical ContextAI

The vulnerability resides in the Linux kernel's drivers/hid/usbhid/ subsystem, specifically in the USB interface driver callbacks hid_pre_reset() and hid_post_reset(). CWE-667 (Improper Locking) identifies the root cause class: a deadlock arises when code executing under a held lock attempts an operation that itself requires the same lock or a dependent resource. In this case, when a composite USB device containing both a HID interface and a storage/UAS interface is reset (because both components share a single USB device and must reset together), the reset path operates within block IO error handling while holding a USB reset mutex. The GFP_KERNEL memory allocations inside the reset handlers can invoke the page reclaim subsystem, which may attempt block IO to free memory. That block IO cannot complete while the block IO error handling mutex is held - creating a circular dependency. CPE cpe:2.3:a:linux:linux:* covers all affected kernel versions from the introducing commit dc3c78e43469063c5bf4b744214508f94c4129f9 onward until each respective stable-branch fix commit.

RemediationAI

The primary fix is to upgrade the Linux kernel to a patched stable release: 5.10.258+ in the 5.10.x branch, 5.15.209+ in 5.15.x, 6.1.175+ in 6.1.x, 6.6.141+ in 6.6.x, 6.12.91+ in 6.12.x, 6.18.33+ in 6.18.x, 7.0.10+ in 7.0.x, or 7.1 in mainline. Patch commits are available at https://git.kernel.org/stable/ (see commits 56d318ef, 90550af0, eeceb6f4, ad4505d2, 4e900465, c7abd0e6, b3d16611, and 8df2c1b4). Ubuntu users should apply USN-8566-1, USN-8567-1, or USN-8568-1 through the standard package manager. As a compensating control where patching is not immediately possible, USB authorization policies (e.g., via /sys/bus/usb/devices/*/authorized or udev rules) can prevent attachment of composite HID+storage USB devices, eliminating the vulnerable code path entirely; trade-off is that legitimate USB keyboard-storage combo devices would also be blocked. Generic USB port disabling at the BIOS/UEFI level is a more disruptive alternative with broader impact.

Vendor StatusVendor

SUSE

Severity: Moderate
Product Status
Image SLES15-SP7-Azure-3P Image SLES15-SP7-Azure-Basic Image SLES15-SP7-Azure-Standard Image SLES15-SP7-HPC-Azure Affected
Image SLES15-SP7-BYOS-Azure Image SLES15-SP7-BYOS-GCE Image SLES15-SP7-CHOST-BYOS-Aliyun Image SLES15-SP7-CHOST-BYOS-Azure Image SLES15-SP7-CHOST-BYOS-EC2 Image SLES15-SP7-CHOST-BYOS-GCE Image SLES15-SP7-CHOST-BYOS-GDC Image SLES15-SP7-CHOST-BYOS-SAP-CCloud Image SLES15-SP7-EC2 Image SLES15-SP7-EC2-ECS-HVM Image SLES15-SP7-GCE Image SLES15-SP7-HPC-BYOS-Azure Image SLES15-SP7-HPC-BYOS-EC2 Image SLES15-SP7-HPC-BYOS-GCE Image SLES15-SP7-Hardened-BYOS-Azure Image SLES15-SP7-Hardened-BYOS-EC2 Image SLES15-SP7-Hardened-BYOS-GCE Image SLES15-SP7-SAPCAL-Azure Image SLES15-SP7-SAPCAL-EC2 Image SLES15-SP7-SAPCAL-GCE Affected
Image SLES15-SP7-SAP-Azure Image SLES15-SP7-SAP-Azure-3P Image SLES15-SP7-SAP-BYOS-Azure Image SLES15-SP7-SAP-BYOS-EC2 Image SLES15-SP7-SAP-BYOS-GCE Image SLES15-SP7-SAP-EC2 Image SLES15-SP7-SAP-GCE Image SLES15-SP7-SAP-Hardened-Azure Image SLES15-SP7-SAP-Hardened-BYOS-Azure Image SLES15-SP7-SAP-Hardened-BYOS-EC2 Image SLES15-SP7-SAP-Hardened-BYOS-GCE Image SLES15-SP7-SAP-Hardened-GCE Affected
SUSE Linux Enterprise Desktop 15 SP7 Fixed
SUSE Linux Enterprise High Availability Extension 15 SP7 Fixed

Share

EUVD-2026-38905 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy