CVE-2024-26745 in Linux
Summary
by MITRE • 04/04/2024
In the Linux kernel, the following vulnerability has been resolved:
powerpc/pseries/iommu: IOMMU table is not initialized for kdump over SR-IOV
When kdump kernel tries to copy dump data over SR-IOV, LPAR panics due to NULL pointer exception:
Kernel attempted to read user page (0) - exploit attempt? (uid: 0) BUG: Kernel NULL pointer dereference on read at 0x00000000 Faulting instruction address: 0xc000000020847ad4 Oops: Kernel access of bad area, sig: 11 [#1]
LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries Modules linked in: mlx5_core(+) vmx_crypto pseries_wdt papr_scm libnvdimm mlxfw tls psample sunrpc fuse overlay squashfs loop CPU: 12 PID: 315 Comm: systemd-udevd Not tainted 6.4.0-Test102+ #12 Hardware name: IBM,9080-HEX POWER10 (raw) 0x800200 0xf000006 of:IBM,FW1060.00 (NH1060_008) hv:phyp pSeries NIP: c000000020847ad4 LR: c00000002083b2dc CTR: 00000000006cd18c REGS: c000000029162ca0 TRAP: 0300 Not tainted (6.4.0-Test102+) MSR: 800000000280b033 CR: 48288244 XER: 00000008 CFAR: c00000002083b2d8 DAR: 0000000000000000 DSISR: 40000000 IRQMASK: 1 ... NIP _find_next_zero_bit+0x24/0x110 LR bitmap_find_next_zero_area_off+0x5c/0xe0 Call Trace: dev_printk_emit+0x38/0x48 (unreliable) iommu_area_alloc+0xc4/0x180 iommu_range_alloc+0x1e8/0x580 iommu_alloc+0x60/0x130 iommu_alloc_coherent+0x158/0x2b0 dma_iommu_alloc_coherent+0x3c/0x50 dma_alloc_attrs+0x170/0x1f0 mlx5_cmd_init+0xc0/0x760 [mlx5_core]
mlx5_function_setup+0xf0/0x510 [mlx5_core]
mlx5_init_one+0x84/0x210 [mlx5_core]
probe_one+0x118/0x2c0 [mlx5_core]
local_pci_probe+0x68/0x110 pci_call_probe+0x68/0x200 pci_device_probe+0xbc/0x1a0 really_probe+0x104/0x540 __driver_probe_device+0xb4/0x230 driver_probe_device+0x54/0x130 __driver_attach+0x158/0x2b0 bus_for_each_dev+0xa8/0x130 driver_attach+0x34/0x50 bus_add_driver+0x16c/0x300 driver_register+0xa4/0x1b0 __pci_register_driver+0x68/0x80 mlx5_init+0xb8/0x100 [mlx5_core]
do_one_initcall+0x60/0x300 do_init_module+0x7c/0x2b0
At the time of LPAR dump, before kexec hands over control to kdump kernel, DDWs (Dynamic DMA Windows) are scanned and added to the FDT. For the SR-IOV case, default DMA window "ibm,dma-window" is removed from the FDT and DDW added, for the device.
Now, kexec hands over control to the kdump kernel.
When the kdump kernel initializes, PCI busses are scanned and IOMMU group/tables created, in pci_dma_bus_setup_pSeriesLP(). For the SR-IOV case, there is no "ibm,dma-window". The original commit: b1fc44eaa9ba, fixes the path where memory is pre-mapped (direct mapped) to the DDW. When TCEs are direct mapped, there is no need to initialize IOMMU tables.
iommu_table_setparms_lpar() only considers "ibm,dma-window" property when initiallizing IOMMU table. In the scenario where TCEs are dynamically allocated for SR-IOV, newly created IOMMU table is not initialized. Later, when the device driver tries to enter TCEs for the SR-IOV device, NULL pointer execption is thrown from iommu_area_alloc().
The fix is to initialize the IOMMU table with DDW property stored in the FDT. There are 2 points to remember:
1. For the dedicated adapter, kdump kernel would encounter both default and DDW in FDT. In this case, DDW property is used to initialize the IOMMU table.
2. A DDW could be direct or dynamic mapped. kdump kernel would initialize IOMMU table and mark the existing DDW as "dynamic". This works fine since, at the time of table initialization, iommu_table_clear() makes some space in the DDW, for some predefined number of TCEs which are needed for kdump to succeed.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/03/2025
The vulnerability CVE-2024-26745 affects the Linux kernel's powerpc/pseries IOMMU implementation and specifically impacts systems utilizing SR-IOV (Single Root I/O Virtualization) with kdump functionality. This issue manifests as a kernel NULL pointer dereference during the kdump process when attempting to copy dump data over SR-IOV devices, leading to LPAR panics and system crashes. The flaw occurs because the IOMMU table initialization logic fails to properly handle the Dynamic DMA Windows (DDWs) that are present in the device tree when kexec transfers control to the kdump kernel, creating a critical operational failure during system crash recovery.
The technical root cause lies in the iommu_table_setparms_lpar() function which only considers the "ibm,dma-window" property when initializing IOMMU tables, completely ignoring DDW properties that are essential for SR-IOV scenarios. During kdump initialization, when PCI busses are scanned and IOMMU groups/tables are created through pci_dma_bus_setup_pSeriesLP(), the system fails to properly initialize the IOMMU table for SR-IOV devices where TCEs are dynamically allocated rather than direct mapped. This oversight results in a NULL pointer exception when device drivers attempt to enter TCEs for SR-IOV devices, specifically manifesting in the iommu_area_alloc() function which is called during the device driver initialization process for mlx5_core network adapters.
The operational impact of this vulnerability is severe as it completely breaks the kdump functionality on systems using SR-IOV capable hardware, rendering crash dump collection impossible during system failures. This effectively eliminates the ability to diagnose and troubleshoot kernel crashes, leaving system administrators without crucial debugging information. The vulnerability affects systems running Linux kernel versions where the fix has not been applied, particularly impacting enterprise systems using POWER10 architecture with Mellanox network adapters that support SR-IOV. The attack surface is limited to systems utilizing kdump with SR-IOV devices, but the impact is critical as it prevents proper system recovery and debugging during kernel panics, which is essential for maintaining system reliability in production environments.
The mitigation strategy involves modifying the IOMMU table initialization logic to properly handle DDW properties stored in the FDT when kdump kernel initializes. The fix requires checking for DDW properties in addition to the traditional "ibm,dma-window" and using them to initialize IOMMU tables for SR-IOV scenarios. This solution must account for both dedicated adapters where both default and DDW properties exist in the FDT, and handle the distinction between direct and dynamic mapped DDWs appropriately. The implementation should ensure that when DDWs are used for IOMMU table initialization, the existing DDW is marked as "dynamic" and properly configured to provide space for the predefined number of TCEs required for successful kdump operations, thus maintaining system stability during crash recovery while preserving the existing functionality for direct mapped scenarios.
This vulnerability aligns with CWE-476 which describes NULL pointer dereference conditions in software systems, and relates to ATT&CK technique T1490 which involves data destruction through system crash or corruption. The issue represents a fundamental failure in the kernel's IOMMU subsystem initialization during the critical kdump process, demonstrating the importance of proper device tree property handling in virtualized and high-availability systems. The fix addresses a gap in the kernel's device initialization logic that was not properly accounting for the dynamic nature of DMA window management in SR-IOV environments, particularly during the transition from the primary kernel to the kdump kernel state.