Cloudanix VulnDB

CVE-2026-23348

Medium · 4.7

CVSS

4.7

EPSS

0.1%

Published

Mar 25, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A timing problem in the Linux kernel when handling certain advanced memory devices can cause the whole system to crash.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
High
Impact
Denial Of Service
Component
OS kernel
Class
Race Condition
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

Race condition between cxl_acpi removal and nvdimm object reprobing leaves nvdimm_bus NULL, causing kobject_get to dereference a NULL dev->parent and trigger kernel NULL pointer dereference in __nd_device_register.

Why it matters to the business

Systems using CXL-attached persistent memory may experience kernel crashes and loss of availability during module load/unload sequences or device rescan operations; low likelihood but high impact on affected servers.

How an attack unfolds

An attacker with local access triggers repeated attachment and removal of CXL ACPI devices while a dependent nvdimm probe is in flight, exploiting the window where the nvdimm_bus is unregistered before the child nvdimm objects are invalidated, leading to the NULL dereference.

How to fix it

Update to a Linux kernel containing the fix that sets PROBE_FORCE_SYNCHRONOUS probe type, adds nvdimm_bus validity checks under locks, marks invalidated nvdimm devices with CXL_NVD_F_INVALIDATED, and moves devm_cxl_add_nvdimm_bridge into pmem.c; apply the referenced patch series if backporting.

How to confirm the fix worked

Confirm the kernel version includes the synchronous probe and lock checks; reproduce the cxl-translate.sh test with the 3-second sleep removed and verify no NULL pointer dereference occurs; inspect dmesg for absence of the kobject_get crash signature after module removal.

Typical attack path

  1. Load cxl_acpi and cxl_pmem modules
  2. Trigger cxl_bus_rescan_queue work item
  3. Remove cxl_acpi while nvdimm objects still reference the bus
  4. Force reprobe of orphaned nvdimm devices
  5. Hit NULL dereference in kobject_get during __nd_device_register

How to detect it

Search kernel logs and dmesg for the exact BUG line referencing NULL pointer dereference at kobject_get combined with the call trace through __nd_device_register, __nvdimm_create, and cxl_nvdimm_probe; correlate with cxl_acpi module unload events.

  • BUG: kernel NULL pointer dereference, address: 000000000000006c
  • RIP: 0010:kobject_get+0xc/0x90
  • Workqueue: cxl_port cxl_bus_rescan_queue [cxl_core]
  • __nd_device_register.part.0+0x4d/0xc0 [libnvdimm]
  • cxl_nvdimm_probe+0x119/0x1d0 [cxl_pmem]

What your security team should do

  • Prioritize kernel updates on CXL-enabled servers within normal patch windows
  • Monitor for kernel oops involving libnvdimm and cxl_pmem in production logs
  • Restrict unprivileged module loading or CXL device attachment where feasible

The record

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) ]

Affected packages

Ecosystem Package Introduced Fixed

Related vulnerabilities