CVE-2022-49371: driver core: fix deadlock in __device_attach
In the Linux kernel, the following vulnerability has been resolved:
driver core: fix deadlock in __device_attach
In __device_attach function, The lock holding logic is as follows:
...
__device_attach
device_lock(dev) // get lock dev
async_schedule_dev(__device_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
__device_attach_async_helper will get lock dev as
well, 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 shown above, when it is allowed to do async probes, because of
out of memory or work limit, async work is not allowed, to do
sync execute instead. it will lead to A-A deadlock because of
__device_attach_async_helper getting lock dev.
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.
Security readout for executives and security teams
Plain-English summary
CVE-2022-49371 is a Linux kernel availability issue. Under specific local conditions, device attachment handling can deadlock, potentially causing affected systems to hang or lose service. The public sources rate it medium with CVSS 5.5, mainly because confidentiality and integrity are not impacted.
Executive priority
Treat as a routine but meaningful availability patch. It is not described as remotely exploitable, but local denial-of-service risk can matter on shared, production, or multi-tenant Linux systems.
Technical view
The flaw is a CWE-667 improper locking issue in __device_attach. When async probe scheduling falls back to synchronous execution because allocation fails or work limits are reached, __device_attach_async_helper can try to take the same device lock already held, causing an A-A deadlock.
Likely exposure
Exposure is most relevant to Linux systems running affected kernel versions or downstream kernels without the stable driver-core fix. The source bundle lists Linux as affected and references stable kernel fixes, but package-specific distro status is not provided.
Exploitation context
The CVSS vector is local, low complexity, low privileges, no user interaction, and high availability impact. The bundle does not identify active exploitation, public weaponization, or KEV listing, so exploitation should not be assumed.
Researcher notes
Focus analysis on driver core locking around __device_attach and async_schedule_dev placement. Evidence supports a deadlock during synchronous fallback from async scheduling. Source data does not provide distro package names, exploit reports, or detailed affected-range semantics.
Mitigation direction
Apply a vendor kernel update containing the referenced stable driver-core fix.
Prioritize systems where local users or workloads can trigger device probing paths.
Check distribution advisories for backported fixes before relying on upstream version numbers.
Plan maintenance windows for kernel updates requiring reboot.
Monitor vendor guidance for corrected affected-version mapping.
Validation and detection
Inventory Linux kernel versions across servers, appliances, and containers with host-kernel dependency.
Compare running kernels against vendor advisories and the referenced stable commits.
Confirm installed kernel changelogs include the __device_attach deadlock fix.
Validate rebooted systems are running the patched kernel, not only installed packages.
Review monitoring for unexplained hangs or availability incidents on affected systems.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cwe · low confidence lookup
CWE-667: Exact CWE lookup
Use the exact CWE identifier as the starting point before reviewing related ATT&CK behavior. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.