In the Linux kernel, the following vulnerability has been resolved:
nvdimm: Fix firmware activation deadlock scenarios
Lockdep reports the following deadlock scenarios for CXL root device
power-management, device_prepare(), operations, and device_shutdown()
operations for 'nd_region' devices:
Chain exists of:
&nvdimm_region_key --> &nvdimm_bus->reconfig_mutex --> system_transition_mutex
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(system_transition_mutex);
lock(&nvdimm_bus->reconfig_mutex);
lock(system_transition_mutex);
lock(&nvdimm_region_key);
Chain exists of:
&cxl_nvdimm_bridge_key --> acpi_scan_lock --> &cxl_root_key
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&cxl_root_key);
lock(acpi_scan_lock);
lock(&cxl_root_key);
lock(&cxl_nvdimm_bridge_key);
These stem from holding nvdimm_bus_lock() over hibernate_quiet_exec()
which walks the entire system device topology taking device_lock() along
the way. The nvdimm_bus_lock() is protecting against unregistration,
multiple simultaneous ops callers, and preventing activate_show() from
racing activate_store(). For the first 2, the lock is redundant.
Unregistration already flushes all ops users, and sysfs already prevents
multiple threads to be active in an ops handler at the same time. For
the last userspace should already be waiting for its last
activate_store() to complete, and does not need activate_show() to flush
the write side, so this lock usage can be deleted in these attributes.
Security readout for executives and security teams
Plain-English summary
This Linux kernel issue can deadlock systems during NVDIMM firmware activation and related power-management or shutdown paths. The business impact is availability, not data theft or tampering. Exploitation requires local access with some privileges, so internet-facing exposure is not indicated by the supplied sources.
Executive priority
Treat this as a moderate availability risk for specialized Linux infrastructure. Patch through normal kernel maintenance, with faster handling for systems using NVDIMM or CXL hardware where a local user could trigger disruptive deadlock conditions.
Technical view
CVE-2022-49446 is a CWE-667 locking flaw in Linux nvdimm firmware activation handling. Holding nvdimm_bus_lock() across hibernate_quiet_exec() can create lock-order inversions involving system_transition_mutex, nvdimm region locks, ACPI scan locking, and CXL root or bridge locks. Stable fixes remove redundant locking around sysfs activation attributes.
Likely exposure
Exposure is likely limited to Linux systems running affected kernel versions and using NVDIMM, persistent memory, or CXL-related device paths. The supplied data lists affected Linux kernel versions including 5.9, 5.10.121, 5.15.46, 5.17.14, 5.18.3, and 5.19, but distribution backports must be checked.
Exploitation context
The CVSS vector is local, low complexity, low privileges, no user interaction, with high availability impact. The source bundle does not report active exploitation, and KEV status is false. No remote attack path, data disclosure, or integrity impact is supported by the provided evidence.
Researcher notes
The vulnerability is grounded in lockdep-reported deadlock scenarios, not a memory corruption primitive. The fix rationale says nvdimm_bus_lock() was redundant because unregistration and sysfs already serialize relevant operations. Evidence is incomplete for distribution-specific affected package ranges.
Mitigation direction
Update to a vendor kernel containing the listed stable fixes.
Check Linux distribution advisories for backported packages and exact affected builds.
Prioritize hosts using NVDIMM, persistent memory, or CXL device support.
Limit untrusted local access to affected systems until patched.
Follow vendor guidance if no fixed package is available.
Validation and detection
Inventory kernel versions across Linux hosts.
Identify systems with NVDIMM, persistent memory, or CXL-related hardware enabled.
Confirm installed kernels include one of the referenced stable fixes or vendor backports.
Review vendor advisories for package-specific fixed versions.
Check operational logs for unexplained hangs during firmware activation, shutdown, or hibernation.
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.
CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.
CWE-667 · source CWE mapping
Improper Locking
Improper Locking represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.