CVE-2022-50149 in Linux
Summary
by MITRE • 06/18/2025
In the Linux kernel, the following vulnerability has been resolved:
driver core: fix potential deadlock in __driver_attach
In __driver_attach function, There are also AA deadlock problem, like the commit b232b02bf3c2 ("driver core: fix deadlock in __device_attach").
stack like commit b232b02bf3c2 ("driver core: fix deadlock in __device_attach"). list below: In __driver_attach function, The lock holding logic is as follows: ... __driver_attach if (driver_allows_async_probing(drv)) device_lock(dev) // get lock dev async_schedule_dev(__driver_attach_async_helper, dev); // func async_schedule_node async_schedule_node_domain(func) entry = kzalloc(sizeof(struct async_entry), GFP_ATOMIC); /* when fail or work limit, sync to execute func, but __driver_attach_async_helper will get lock dev as will, which will lead to A-A deadlock. */ if (!entry || atomic_read(&entry_count) > MAX_WORK) {
func; else queue_work_node(node, system_unbound_wq, &entry->work) device_unlock(dev)
As above show, when it is allowed to do async probes, because of out of memory or work limit, async work is not be allowed, to do sync execute instead. it will lead to A-A deadlock because of __driver_attach_async_helper getting lock dev.
Reproduce: and it can be reproduce by make the condition (if (!entry || atomic_read(&entry_count) > MAX_WORK)) untenable, like below:
[ 370.785650] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables
this message. [ 370.787154] task:swapper/0 state:D stack: 0 pid: 1 ppid:
0 flags:0x00004000 [ 370.788865] Call Trace:
[ 370.789374] <TASK>
[ 370.789841] __schedule+0x482/0x1050
[ 370.790613] schedule+0x92/0x1a0
[ 370.791290] schedule_preempt_disabled+0x2c/0x50
[ 370.792256] __mutex_lock.isra.0+0x757/0xec0
[ 370.793158] __mutex_lock_slowpath+0x1f/0x30
[ 370.794079] mutex_lock+0x50/0x60
[ 370.794795] __device_driver_lock+0x2f/0x70
[ 370.795677] ? driver_probe_device+0xd0/0xd0
[ 370.796576] __driver_attach_async_helper+0x1d/0xd0
[ 370.797318] ? driver_probe_device+0xd0/0xd0
[ 370.797957] async_schedule_node_domain+0xa5/0xc0
[ 370.798652] async_schedule_node+0x19/0x30
[ 370.799243] __driver_attach+0x246/0x290
[ 370.799828] ? driver_allows_async_probing+0xa0/0xa0
[ 370.800548] bus_for_each_dev+0x9d/0x130
[ 370.801132] driver_attach+0x22/0x30
[ 370.801666] bus_add_driver+0x290/0x340
[ 370.802246] driver_register+0x88/0x140
[ 370.802817] ? virtio_scsi_init+0x116/0x116
[ 370.803425] scsi_register_driver+0x1a/0x30
[ 370.804057] init_sd+0x184/0x226
[ 370.804533] do_one_initcall+0x71/0x3a0
[ 370.805107] kernel_init_freeable+0x39a/0x43a
[ 370.805759] ? rest_init+0x150/0x150
[ 370.806283] kernel_init+0x26/0x230
[ 370.806799] ret_from_fork+0x1f/0x30
To fix the deadlock, move the async_schedule_dev outside device_lock, as we can see, in async_schedule_node_domain, the parameter of queue_work_node is system_unbound_wq, so it can accept concurrent operations. which will also not change the code logic, and will not lead to deadlock.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 03/20/2026
The vulnerability CVE-2022-50149 represents a critical deadlock condition within the Linux kernel's driver core subsystem, specifically in the __driver_attach function. This flaw manifests as an A-A (self-deadlock) scenario that occurs during asynchronous device driver probing operations. The issue stems from improper lock ordering where the same device lock is acquired twice in different contexts, creating a circular dependency that halts system progress. The vulnerability is particularly significant because it affects the fundamental device enumeration and driver attachment mechanisms that are essential for system boot and runtime device management. The problem is classified under CWE-362 (Concurrent Execution using Shared Resource with Unprotected Critical Section) and aligns with ATT&CK technique T1059.003 (Command and Scripting Interpreter: Windows Command Shell) in its potential to cause system instability and denial of service conditions.
The technical implementation of this vulnerability occurs when the kernel attempts to schedule asynchronous device probing operations through the async_schedule_dev mechanism. During normal operation, when driver_allows_async_probing returns true, the __driver_attach function acquires a device lock before scheduling an asynchronous helper function __driver_attach_async_helper. However, under specific failure conditions such as memory allocation exhaustion or reaching work queue limits, the system falls back to synchronous execution. This fallback path creates the deadlock scenario because the synchronous execution path within __driver_attach_async_helper attempts to acquire the same device lock that was already held by the calling function, resulting in a circular wait condition. The kernel's lock hierarchy management fails to account for this specific execution path, leading to a state where the system cannot proceed with device enumeration and driver attachment.
The operational impact of CVE-2022-50149 is severe and can result in complete system hang or deadlock during the boot process or when dynamically loading device drivers. The vulnerability is particularly dangerous during system initialization when the kernel attempts to enumerate and attach drivers to hardware devices, as this represents a critical system operation that must complete successfully for proper system functionality. When triggered, the deadlock prevents further device discovery and driver loading, potentially rendering hardware devices unusable or causing the entire system to become unresponsive. This vulnerability affects all Linux kernel versions where the driver core subsystem is implemented, particularly impacting server and embedded systems where device enumeration during boot is critical. The issue is classified as a high-severity vulnerability under the CVSS scoring system, with potential for denial of service and system instability.
The fix for CVE-2022-50149 involves a straightforward but crucial code restructuring that moves the async_schedule_dev call outside of the device lock scope. This change ensures that asynchronous work scheduling occurs without holding the device lock, thereby eliminating the potential for self-deadlock conditions. The solution maintains the original functional behavior while eliminating the race condition that led to the deadlock. The implementation follows the established pattern from a previous fix for a similar issue in the __device_attach function, demonstrating consistency in kernel development practices. This approach leverages the fact that the work queue system used by async_schedule_dev can handle concurrent operations properly, removing the need to hold the device lock during the scheduling phase. The mitigation strategy is minimal and focused, requiring only the reordering of lock acquisition and release operations without altering the core driver attachment logic or introducing additional complexity to the system.