CVE-2023-54323
Unknown Unknown - Not Provided
Use-After-Free Race Condition in Linux Kernel cxl_pmem NVDIMM Registration

Publication date: 2025-12-30

Last updated on: 2025-12-30

Assigner: kernel.org

Description
In the Linux kernel, the following vulnerability has been resolved: cxl/pmem: Fix nvdimm registration races A loop of the form: while true; do modprobe cxl_pci; modprobe -r cxl_pci; done ...fails with the following crash signature: BUG: kernel NULL pointer dereference, address: 0000000000000040 [..] RIP: 0010:cxl_internal_send_cmd+0x5/0xb0 [cxl_core] [..] Call Trace: <TASK> cxl_pmem_ctl+0x121/0x240 [cxl_pmem] nvdimm_get_config_data+0xd6/0x1a0 [libnvdimm] nd_label_data_init+0x135/0x7e0 [libnvdimm] nvdimm_probe+0xd6/0x1c0 [libnvdimm] nvdimm_bus_probe+0x7a/0x1e0 [libnvdimm] really_probe+0xde/0x380 __driver_probe_device+0x78/0x170 driver_probe_device+0x1f/0x90 __device_attach_driver+0x85/0x110 bus_for_each_drv+0x7d/0xc0 __device_attach+0xb4/0x1e0 bus_probe_device+0x9f/0xc0 device_add+0x445/0x9c0 nd_async_device_register+0xe/0x40 [libnvdimm] async_run_entry_fn+0x30/0x130 ...namely that the bottom half of async nvdimm device registration runs after the CXL has already torn down the context that cxl_pmem_ctl() needs. Unlike the ACPI NFIT case that benefits from launching multiple nvdimm device registrations in parallel from those listed in the table, CXL is already marked PROBE_PREFER_ASYNCHRONOUS. So provide for a synchronous registration path to preclude this scenario.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2025-12-30
Last Modified
2025-12-30
Generated
2026-05-07
AI Q&A
2025-12-30
EPSS Evaluated
2026-05-05
NVD
EUVD
Affected Vendors & Products
Showing 4 associated CPEs
Vendor Product Version / Range
linux libnvdimm *
linux cxl_core *
linux cxl_pmem *
linux linux_kernel *
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability is a race condition in the Linux kernel's cxl/pmem subsystem related to nvdimm device registration. Specifically, repeatedly loading and unloading the cxl_pci module can cause a kernel crash due to a NULL pointer dereference. The issue arises because the asynchronous registration of nvdimm devices happens after the CXL context they depend on has been torn down, leading to a use-after-free or invalid memory access. The fix involves providing a synchronous registration path to avoid this race condition.


How can this vulnerability impact me? :

This vulnerability can cause the Linux kernel to crash (kernel panic) when the cxl_pci module is repeatedly loaded and unloaded. Such crashes can lead to system instability, downtime, and potential data loss or corruption if the system is in use during the crash.


How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability can be detected by running a loop that repeatedly loads and unloads the cxl_pci module and observing if the system crashes with a kernel NULL pointer dereference. For example, the command: while true; do modprobe cxl_pci; modprobe -r cxl_pci; done can be used to test for the crash signature described.


What immediate steps should I take to mitigate this vulnerability?

Immediate mitigation involves avoiding the repeated loading and unloading of the cxl_pci module to prevent triggering the race condition and kernel crash. Applying the patch or update that fixes the nvdimm registration races in the Linux kernel is the recommended long-term solution.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart