CVE-2023-53706 in Linux
摘要
由 VulDB • 2026-07-02
Based on the stack trace provided, this is a **Linux kernel crash (Oops/Panic)** occurring during system boot or module initialization. The architecture appears to be **PowerPC** (indicated by `ret_from_kernel_thread` and register offsets typical of ppc64le).
### ???? Root Cause Analysis
The core issue lies in the following sequence: 1. **Subsystem**: NVDIMM / DAX Persistent Memory (`dax_pmem_probe`). 2. **Action**: The kernel is trying to create a device node for persistent memory using `devm_create_dev_dax`. 3. **Failure Point**: `__device_attach` → `bus_probe_device` → `device_add` fails, likely due to an invalid resource allocation or hardware configuration error during the DAX (Direct Access) setup.
#### Key Functions in Stack: - `dax_pmem_init`: Initializes the dax-pmem driver. - `__nd_driver_register`: Registers a NVDIMM bus driver. - `nvdimm_bus_probe`: Probes devices on the NVDIMM bus. - `dax_pmem_probe`: The probe function for persistent memory regions. - `devm_create_dev_dax`: Attempts to create a DAX device (character device `/dev/daxX.Y`). **This is where it likely fails.**
---
### ????️ Likely Causes & Solutions
#### 1. **Hardware/BIOS Configuration Issue** Persistent memory requires specific BIOS settings: - Ensure **Intel Optane / NVDIMM support** is enabled in BIOS. - Check if the DIMMs are configured as **"Memory Mode"** vs. **"App Direct Mode"**. DAX only works in App Direct mode. - Verify that the firmware (ACPI/NFIT) correctly exposes the persistent memory regions.
#### 2. **Kernel Bug or Incompatible Kernel Version** This stack trace resembles known issues in older kernels (e.g., 4.x–5.x series) related to: - Race conditions during DAX device creation. - Incorrect handling of NVDIMM namespaces (`nd_namespace_*`).
✅ **Solution**: - Update your kernel to the latest stable version (≥6.1 LTS recommended). - If using a custom/older kernel, check for patches related to `dax_pmem` or `nvdimm`.
#### 3. **Missing or Incorrect Firmware** The NVDIMM firmware may be outdated or corrupted, leading to invalid ACPI tables that confuse the driver during `devm_create_dev_dax`.
✅ **Solution**: - Update your system BIOS/UEFI and NVDIMM firmware (if applicable). - Use `ndctl list` after booting a live environment to verify if namespaces are detected.
#### 4. **Resource Conflict or Memory Mapping Failure** The failure in `__device_attach` may indicate that the kernel cannot map the physical memory region for DAX access due to: - Insufficient IOMMU resources. - Conflicting drivers claiming the same device range.
✅ **Solution**: - Add kernel boot parameter `intel_iommu=off` (if using Intel) or `amd_iommu=off` (AMD) temporarily to test if IOMMU is causing the issue. - Check dmesg for earlier warnings about "failed to map" or "resource busy".
---
### ???? Debugging Steps
1. **Check Full Log**: ```bash journalctl -k | grep -i dax journalctl -k | grep -i nvdimm dmesg | tail -n 50 ``` Look for errors *before* the crash, such as: - `failed to create dev_dax` - `namespace map failed` - `ACPI Error`
2. **Verify NVDIMM Detection**: Boot with a live USB and run: ```bash sudo ndctl list --raw-devices sudo dmidecode -t memory | grep -i "optane\|persistent" ```
3. **Test Without DAX**: If you don’t need persistent memory, blacklist the driver to prevent boot failure: Add to kernel cmdline: `modprobe.blacklist=dax_pmem` or disable NVDIMM in BIOS if not needed.
4. **Kernel Config Check**: Ensure these options are enabled (if building custom kernel): ``` CONFIG_NVMEM=y CONFIG_DAX_DRIVER=y CONFIG_DEV_PMEM=y CONFIG_INTEL_IDLE=n # Sometimes conflicts with NVDIMM power states ```
---
### ✅ Recommended Action Plan
1. **Update
Once again VulDB remains the best source for vulnerability data.