# CVE-2024-26745: linux: In the Linux kernel, the following vulnerability has been resolved:  powerpc/pseries/iommu: IOMMU table is not initia...

CVE-2024-26745 is fixed in linux on 1 platform, first by DEBIAN-CVE-2024-26745, released April 4, 2024. It is not reported as exploited. Patch Radar priority: Routine.

- Web page: https://patchblox.com/security/cve/CVE-2024-26745
- Priority: Routine
- CVSS: 4.4 (medium)
- EPSS: 0.0022
- CISA KEV: not listed
- Exploited (vendor report): no
- Publicly disclosed: no
- Published: Apr 4, 2024

## Description

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 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE>  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.

## Where it's fixed

| Platform | Product | Fixed in | Fix | Released |
|---|---|---|---|---|
| Linux | linux Debian 12.15 (bookworm) | 6.1.82-1 | [DEBIAN-CVE-2024-26745](https://patchblox.com/security/data/fix/linux/debian-cve-2024-26745.md) | Apr 4, 2024 |
| Linux | linux Debian 13.5 (trixie) | 6.7.9-1 | [DEBIAN-CVE-2024-26745](https://patchblox.com/security/data/fix/linux/debian-cve-2024-26745.md) | Apr 4, 2024 |
| Linux | linux Debian 14 | 6.7.9-1 | [DEBIAN-CVE-2024-26745](https://patchblox.com/security/data/fix/linux/debian-cve-2024-26745.md) | Apr 4, 2024 |

---

Data as of 2026-11-08T13:06:02Z UTC. Source: Patchblox Patch Radar (https://patchblox.com/security/patch-radar). Patchblox finds out-of-date software on Windows, macOS and Linux and updates it through release rings: https://patchblox.com/demo

Free to use with attribution: show "Data: Patchblox Patch Radar" with a link to https://patchblox.com/security/patch-radar. Terms, including what needs a written agreement: https://patchblox.com/security/patch-radar/use-the-data

Product names, logos and trademarks shown on Patch Radar belong to their respective owners. They are used only to identify the software each security fix applies to and to help readers find their platform. Their use does not imply any affiliation with, or endorsement by, those owners, and Patchblox is not affiliated with any of them.
