CVE-2024-26745

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/pseries/iommu: IOMMU table is not initialized for kdump over SR-IOV<br /> <br /> When kdump kernel tries to copy dump data over SR-IOV, LPAR panics due<br /> to NULL pointer exception:<br /> <br /> Kernel attempted to read user page (0) - exploit attempt? (uid: 0)<br /> BUG: Kernel NULL pointer dereference on read at 0x00000000<br /> Faulting instruction address: 0xc000000020847ad4<br /> Oops: Kernel access of bad area, sig: 11 [#1]<br /> LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries<br /> Modules linked in: mlx5_core(+) vmx_crypto pseries_wdt papr_scm libnvdimm mlxfw tls psample sunrpc fuse overlay squashfs loop<br /> CPU: 12 PID: 315 Comm: systemd-udevd Not tainted 6.4.0-Test102+ #12<br /> Hardware name: IBM,9080-HEX POWER10 (raw) 0x800200 0xf000006 of:IBM,FW1060.00 (NH1060_008) hv:phyp pSeries<br /> NIP: c000000020847ad4 LR: c00000002083b2dc CTR: 00000000006cd18c<br /> REGS: c000000029162ca0 TRAP: 0300 Not tainted (6.4.0-Test102+)<br /> MSR: 800000000280b033 CR: 48288244 XER: 00000008<br /> CFAR: c00000002083b2d8 DAR: 0000000000000000 DSISR: 40000000 IRQMASK: 1<br /> ...<br /> NIP _find_next_zero_bit+0x24/0x110<br /> LR bitmap_find_next_zero_area_off+0x5c/0xe0<br /> Call Trace:<br /> dev_printk_emit+0x38/0x48 (unreliable)<br /> iommu_area_alloc+0xc4/0x180<br /> iommu_range_alloc+0x1e8/0x580<br /> iommu_alloc+0x60/0x130<br /> iommu_alloc_coherent+0x158/0x2b0<br /> dma_iommu_alloc_coherent+0x3c/0x50<br /> dma_alloc_attrs+0x170/0x1f0<br /> mlx5_cmd_init+0xc0/0x760 [mlx5_core]<br /> mlx5_function_setup+0xf0/0x510 [mlx5_core]<br /> mlx5_init_one+0x84/0x210 [mlx5_core]<br /> probe_one+0x118/0x2c0 [mlx5_core]<br /> local_pci_probe+0x68/0x110<br /> pci_call_probe+0x68/0x200<br /> pci_device_probe+0xbc/0x1a0<br /> really_probe+0x104/0x540<br /> __driver_probe_device+0xb4/0x230<br /> driver_probe_device+0x54/0x130<br /> __driver_attach+0x158/0x2b0<br /> bus_for_each_dev+0xa8/0x130<br /> driver_attach+0x34/0x50<br /> bus_add_driver+0x16c/0x300<br /> driver_register+0xa4/0x1b0<br /> __pci_register_driver+0x68/0x80<br /> mlx5_init+0xb8/0x100 [mlx5_core]<br /> do_one_initcall+0x60/0x300<br /> do_init_module+0x7c/0x2b0<br /> <br /> At the time of LPAR dump, before kexec hands over control to kdump<br /> kernel, DDWs (Dynamic DMA Windows) are scanned and added to the FDT.<br /> For the SR-IOV case, default DMA window "ibm,dma-window" is removed from<br /> the FDT and DDW added, for the device.<br /> <br /> Now, kexec hands over control to the kdump kernel.<br /> <br /> When the kdump kernel initializes, PCI busses are scanned and IOMMU<br /> group/tables created, in pci_dma_bus_setup_pSeriesLP(). For the SR-IOV<br /> case, there is no "ibm,dma-window". The original commit: b1fc44eaa9ba,<br /> fixes the path where memory is pre-mapped (direct mapped) to the DDW.<br /> When TCEs are direct mapped, there is no need to initialize IOMMU<br /> tables.<br /> <br /> iommu_table_setparms_lpar() only considers "ibm,dma-window" property<br /> when initiallizing IOMMU table. In the scenario where TCEs are<br /> dynamically allocated for SR-IOV, newly created IOMMU table is not<br /> initialized. Later, when the device driver tries to enter TCEs for the<br /> SR-IOV device, NULL pointer execption is thrown from iommu_area_alloc().<br /> <br /> The fix is to initialize the IOMMU table with DDW property stored in the<br /> FDT. There are 2 points to remember:<br /> <br /> 1. For the dedicated adapter, kdump kernel would encounter both<br /> default and DDW in FDT. In this case, DDW property is used to<br /> initialize the IOMMU table.<br /> <br /> 2. A DDW could be direct or dynamic mapped. kdump kernel would<br /> initialize IOMMU table and mark the existing DDW as<br /> "dynamic". This works fine since, at the time of table<br /> initialization, iommu_table_clear() makes some space in the<br /> DDW, for some predefined number of TCEs which are needed for<br /> kdump to succeed.