CVE-2026-23348
Received Received - Intake
Race Condition in Linux Kernel cxl_nvdimm Causes NULL Pointer Dereference

Publication date: 2026-03-25

Last updated on: 2026-04-24

Assigner: kernel.org

Description
In the Linux kernel, the following vulnerability has been resolved: cxl: Fix race of nvdimm_bus object when creating nvdimm objects Found issue during running of cxl-translate.sh unit test. Adding a 3s sleep right before the test seems to make the issue reproduce fairly consistently. The cxl_translate module has dependency on cxl_acpi and causes orphaned nvdimm objects to reprobe after cxl_acpi is removed. The nvdimm_bus object is registered by the cxl_nvb object when cxl_acpi_probe() is called. With the nvdimm_bus object missing, __nd_device_register() will trigger NULL pointer dereference when accessing the dev->parent that points to &nvdimm_bus->dev. [ 192.884510] BUG: kernel NULL pointer dereference, address: 000000000000006c [ 192.895383] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS edk2-20250812-19.fc42 08/12/2025 [ 192.897721] Workqueue: cxl_port cxl_bus_rescan_queue [cxl_core] [ 192.899459] RIP: 0010:kobject_get+0xc/0x90 [ 192.924871] Call Trace: [ 192.925959] <TASK> [ 192.926976] ? pm_runtime_init+0xb9/0xe0 [ 192.929712] __nd_device_register.part.0+0x4d/0xc0 [libnvdimm] [ 192.933314] __nvdimm_create+0x206/0x290 [libnvdimm] [ 192.936662] cxl_nvdimm_probe+0x119/0x1d0 [cxl_pmem] [ 192.940245] cxl_bus_probe+0x1a/0x60 [cxl_core] [ 192.943349] really_probe+0xde/0x380 This patch also relies on the previous change where devm_cxl_add_nvdimm_bridge() is called from drivers/cxl/pmem.c instead of drivers/cxl/core.c to ensure the dependency of cxl_acpi on cxl_pmem. 1. Set probe_type of cxl_nvb to PROBE_FORCE_SYNCHRONOUS to ensure the driver is probed synchronously when add_device() is called. 2. Add a check in __devm_cxl_add_nvdimm_bridge() to ensure that the cxl_nvb driver is attached during cxl_acpi_probe(). 3. Take the cxl_root uport_dev lock and the cxl_nvb->dev lock in devm_cxl_add_nvdimm() before checking nvdimm_bus is valid. 4. Set cxl_nvdimm flag to CXL_NVD_F_INVALIDATED so cxl_nvdimm_probe() will exit with -EBUSY. The removal of cxl_nvdimm devices should prevent any orphaned devices from probing once the nvdimm_bus is gone. [ dj: Fixed 0-day reported kdoc issue. ] [ dj: Fix cxl_nvb reference leak on error. Gregory (kreview-0811365) ]
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-03-25
Last Modified
2026-04-24
Generated
2026-05-07
AI Q&A
2026-03-25
EPSS Evaluated
2026-05-05
NVD
EUVD
Affected Vendors & Products
Showing 10 associated CPEs
Vendor Product Version / Range
linux linux_kernel 5.14
linux linux_kernel From 6.19 (inc) to 6.19.7 (exc)
linux linux_kernel 7.0
linux linux_kernel 7.0
linux linux_kernel 7.0
linux linux_kernel 7.0
linux linux_kernel 7.0
linux linux_kernel 7.0
linux linux_kernel 7.0
linux linux_kernel From 5.14.1 (inc) to 6.18.17 (exc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-362 The product contains a concurrent code sequence that requires temporary, exclusive access to a shared resource, but a timing window exists in which the shared resource can be modified by another code sequence operating concurrently.
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability exists in the Linux kernel's cxl (Compute Express Link) subsystem, specifically involving a race condition with the nvdimm_bus object when creating nvdimm devices.

The issue occurs because the cxl_translate module depends on cxl_acpi, and when cxl_acpi is removed, orphaned nvdimm objects attempt to reprobe. During this process, the nvdimm_bus object, which should be registered by the cxl_nvb object during cxl_acpi_probe(), may be missing.

If the nvdimm_bus object is missing, the function __nd_device_register() tries to access a NULL pointer (dev->parent pointing to &nvdimm_bus->dev), causing a kernel NULL pointer dereference and a crash.

The fix involves ensuring synchronous probing of the cxl_nvb driver, adding checks to confirm the driver is attached, locking mechanisms to validate nvdimm_bus, and marking cxl_nvdimm devices as invalidated to prevent orphaned devices from probing after the nvdimm_bus is removed.


How can this vulnerability impact me? :

This vulnerability can cause a kernel NULL pointer dereference, leading to a kernel crash (kernel panic) or system instability.

Such crashes can result in denial of service, where the affected system becomes unresponsive or requires a reboot.

In environments relying on the cxl subsystem and nvdimm devices, this could disrupt normal operations, potentially causing data loss or downtime.


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

This vulnerability manifests as a kernel NULL pointer dereference related to the cxl and nvdimm_bus objects in the Linux kernel. Detection can be done by monitoring kernel logs for specific error messages indicating this issue.

  • Check kernel logs for messages similar to: "BUG: kernel NULL pointer dereference, address: 000000000000006c".
  • Look for call traces involving cxl_core, cxl_pmem, and libnvdimm modules, especially functions like __nd_device_register, cxl_nvdimm_probe, and cxl_bus_probe.
  • Use the command: dmesg | grep -i 'NULL pointer dereference' to filter relevant kernel messages.
  • Monitor for errors during the execution of cxl-translate.sh unit test or similar tests that exercise the cxl_translate module.

What immediate steps should I take to mitigate this vulnerability?

Immediate mitigation involves applying the patch that fixes the race condition in the cxl and nvdimm_bus object handling in the Linux kernel.

  • Ensure the cxl_nvb driver is probed synchronously by setting probe_type to PROBE_FORCE_SYNCHRONOUS.
  • Add checks to ensure the cxl_nvb driver is attached during cxl_acpi_probe.
  • Take appropriate locks (cxl_root uport_dev lock and cxl_nvb->dev lock) before validating nvdimm_bus.
  • Set the cxl_nvdimm flag to CXL_NVD_F_INVALIDATED so that cxl_nvdimm_probe exits with -EBUSY, preventing orphaned device probing.

Removing cxl_nvdimm devices prevents orphaned devices from reprobe after cxl_acpi removal, which is part of the fix.


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