CVE-2026-23348: Linux Kernel Race Condition Vulnerability

CVE-2026-23348 Overview

A race condition vulnerability has been identified in the Linux kernel's CXL (Compute Express Link) subsystem that can trigger a NULL pointer dereference when creating nvdimm objects. The vulnerability occurs due to improper synchronization between the nvdimm_bus object lifecycle and nvdimm device registration, leading to kernel crashes when the cxl_acpi module is removed while orphaned nvdimm devices attempt to reprobe.

Critical Impact

This vulnerability can cause kernel NULL pointer dereference crashes, resulting in system instability and potential denial of service conditions on systems using CXL memory devices.

Affected Products

• Linux kernel with CXL (Compute Express Link) subsystem enabled
• Systems using cxl_acpi, cxl_pmem, and libnvdimm kernel modules
• QEMU virtualized environments with CXL memory simulation

Discovery Timeline

• 2026-03-25 - CVE CVE-2026-23348 published to NVD
• 2026-03-25 - Last updated in NVD database

Technical Details for CVE-2026-23348

Vulnerability Analysis

The vulnerability resides in the CXL subsystem's handling of nvdimm device registration. When the cxl_translate module creates a dependency on cxl_acpi, orphaned nvdimm objects can attempt to reprobe after cxl_acpi is removed. The nvdimm_bus object, which is registered by the cxl_nvb object during cxl_acpi_probe(), becomes unavailable before the nvdimm devices complete their deregistration.

The race condition manifests in the __nd_device_register() function, where accessing dev->parent (which points to &nvdimm_bus->dev) triggers a NULL pointer dereference at memory address 0x6c. This occurs because the parent device structure has already been freed while the nvdimm device registration is still in progress on the cxl_bus_rescan_queue workqueue.

Root Cause

The root cause is a missing synchronization mechanism between the nvdimm_bus object lifecycle and the nvdimm device probe/registration process. Specifically:

1. The cxl_nvb driver probe is asynchronous, allowing device registration to proceed before the nvdimm_bus is fully initialized
2. No lock is held on the cxl_root uport_dev or cxl_nvb->dev when checking nvdimm_bus validity
3. Orphaned nvdimm devices are not prevented from reprobing after module removal begins

Attack Vector

The vulnerability is triggered through local system manipulation involving kernel module loading/unloading operations. An attacker with local access and appropriate privileges could potentially trigger this condition by:

The crash occurs in the kernel workqueue context (cxl_port cxl_bus_rescan_queue) during the cxl_nvdimm_probe execution path. The call trace shows the NULL pointer dereference occurring in kobject_get() when called from __nd_device_register.part.0() in the libnvdimm module.

The kernel panic includes the following notable elements:

• BUG type: kernel NULL pointer dereference at address 0x6c
• Faulting instruction: kobject_get+0xc/0x90
• Workqueue: cxl_port cxl_bus_rescan_queue [cxl_core]
• Module chain: cxl_pmem → libnvdimm → cxl_core

Detection Methods for CVE-2026-23348

Indicators of Compromise

• Kernel panic messages containing "BUG: kernel NULL pointer dereference" with address 0x6c
• Stack traces showing __nd_device_register or cxl_nvdimm_probe in the call chain
• System logs indicating workqueue failures in cxl_bus_rescan_queue
• Unexpected system crashes during CXL module loading or unloading operations

Detection Strategies

• Monitor kernel logs (dmesg/journald) for NULL pointer dereference events in CXL or nvdimm-related code paths
• Implement kernel crash dump analysis to identify race condition patterns in CXL subsystem
• Track module loading/unloading sequences for cxl_acpi, cxl_pmem, and cxl_translate modules
• Deploy kernel live patching detection to verify vulnerable systems

Monitoring Recommendations

• Enable kernel crash dump collection (kdump) to capture detailed state during system crashes
• Configure auditd rules to monitor kernel module load/unload events for CXL-related modules
• Implement automated log parsing for CXL subsystem error patterns
• Monitor system stability metrics on servers with CXL-enabled hardware or virtualization

How to Mitigate CVE-2026-23348

Immediate Actions Required

• Update to a patched Linux kernel version containing the fix commits
• Avoid rapid loading/unloading cycles of CXL-related kernel modules on production systems
• Consider temporarily disabling CXL subsystem if not required for operations
• Implement system monitoring to detect and alert on kernel panics related to this issue

Patch Information

The vulnerability has been resolved through multiple kernel commits that implement proper synchronization:

1. Set probe_type of cxl_nvb to PROBE_FORCE_SYNCHRONOUS ensuring synchronous driver probing during add_device()
2. Added validation in __devm_cxl_add_nvdimm_bridge() to verify cxl_nvb driver attachment during cxl_acpi_probe()
3. Implemented locking on cxl_root uport_dev and cxl_nvb->dev in devm_cxl_add_nvdimm() before validating nvdimm_bus
4. Added CXL_NVD_F_INVALIDATED flag to cause cxl_nvdimm_probe() to exit with -EBUSY when appropriate

Relevant patches are available from the kernel Git repository:

• Kernel Git Commit Update
• Kernel Git Commit Patch
• Kernel Git Commit Fix

Workarounds

• Avoid running cxl-translate.sh unit tests or similar CXL diagnostic tools on production systems until patched
• Implement module loading delays when working with CXL subsystem components
• Configure systems to prevent automatic module unloading of CXL components
• Use kernel module blacklisting to prevent loading of cxl_translate if not needed

# Prevent automatic CXL module unloading (temporary workaround)
echo "options cxl_acpi dyndbg=+p" >> /etc/modprobe.d/cxl-workaround.conf

# Blacklist cxl_translate if not required
echo "blacklist cxl_translate" >> /etc/modprobe.d/cxl-blacklist.conf

# Verify current module state
lsmod | grep -E "(cxl|nvdimm)"