CVE-2024-26891 in Linux
Riassunto
di VulDB • 29/06/2026
Based on the kernel log provided, here is an analysis of the issue and recommended troubleshooting steps.
### **Summary** The system experienced a **Hard LOCKUP** (CPU watchdog timeout) while handling a PCIe hot-plug event (`irq/57-pciehp`). The crash occurred during device removal/cleanup in the IOMMU subsystem (`intel_iommu_release_device`), specifically when trying to detach a PCI device from its DMA mappings.
---
### **Key Observations** 1. **Trigger**: `pciehp_ist` (PCI Express Hotplug Interrupt Service Thread) detected a presence/link change and initiated device removal. 2. **Crash Location**: The lockup happened in the call chain: ``` pciehp_handle_presence_or_link_change → pciehp_disable_slot → pci_remove_bus_device → iommu_release_device → intel_iommu_release_device → dmar_remove_one_dev_info → __dmar_remove_one_dev_info ``` 3. **Error Type**: `Hard LOCKUP` indicates that a CPU core (CPU 144) was stuck in kernel mode for longer than the watchdog threshold (typically ~6–20 seconds, depending on config). This is often caused by: - A spinlock deadlock. - An infinite loop in atomic context. - Hardware/firmware bug causing a hang during DMA/IOMMU teardown.
4. **Taint Flags**: `OE` means the kernel was loaded with an out-of-tree module (`O`) and/or unsigned modules were used (`E`). This may indicate custom drivers or firmware interactions are involved.
---
### **Likely Causes** 1. **IOMMU/DMA Teardown Bug**: The Intel IOMMU driver is hanging while trying to remove DMA mappings for a device that was being hot-removed. This can happen if: - A pending DMA transaction from the device never completed, causing the IOMMU flush or TLB invalidation to hang. - Firmware (BIOS/UEFI) reports incorrect PCIe topology or capabilities during removal.
2. **PCIe Hotplug Race Condition**: The hot-plug controller (`pciehp`) and the IOMMU subsystem may have a race condition when tearing down devices, especially if multiple interrupts are pending.
3. **Hardware/Firmware Issue**: - Faulty PCIe slot or device causing spurious link-down events. - BIOS bug in handling ACPI/PCIe hot-plug notifications.
4. **Kernel Bug**: A known issue in the `intel_iommu` driver with certain hardware configurations (common in older kernels).
---
### **Recommended Troubleshooting Steps**
#### **1. Update Kernel and Firmware** - **Upgrade Linux Kernel**: This bug may have been fixed in newer kernel versions. Check if your current version is EOL or has known IOMMU hot-plug bugs. Try a recent stable LTS (e.g., 6.1, 6.6) or mainline. - **Update BIOS/UEFI**: Vendor-specific fixes for PCIe hot-plug and IOMMU behavior are often released in BIOS updates.
#### **2. Disable Intel IOMMU Temporarily** To confirm if the issue is IOMMU-related: ```bash # Add to kernel boot parameters (GRUB_CMDLINE_LINUX) intel_iommu=off ``` Reboot and test hot-plug operations. If the crash stops, the root cause is in the IOMMU driver or hardware interaction with DMA.
#### **3. Disable PCIe Hotplug** If you don’t need hot-plugging: ```bash # Add to kernel boot parameters pciehp.disable=1 ``` Or disable it via sysfs if already running (requires root): ```bash echo 0 | sudo tee /sys/bus/pci/slots/*/power_on ```
#### **4. Check for Pending DMA Transactions** If the device being removed was actively transferring data, this could cause a hang. Ensure proper driver cleanup before removal: - Verify that drivers for devices in the slot properly handle `remove()` callbacks and stop all DMA activity. - If using SR-IOV or VFIO, ensure virtual functions are released cleanly.
#### **5. Enable Debugging** Add these kernel parameters to get more details on the next crash: ```bash intel_iommu=on iommu.debug=1 pciehp.force_hotplug=0 ``` Also enable `CONFIG_DEBUG_SPINLOCK` and `CONFIG_PROVE_LOCKING` in your kernel config if you can rebuild it.
#### **6. Check dmesg for Earlier Warnings** Look at logs *before* the crash (timestamp ~4223s) for: - PCIe
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.