CVE-2024-26745 Information
Share on: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: IBM9080-HEX POWER10 (raw) 0x800200 0xf000006 of:IBMFW1060.00 (NH1060_008) hv:phyp pSeries
NIP: c000000020847ad4 LR: c00000002083b2dc CTR: 00000000006cd18c
REGS: c000000029162ca0 TRAP: 0300 Not tainted (6.4.0-Test102+)
MSR: 800000000280b033
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 \ibmdma-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 \ibmdma-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 \ibmdma-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. ## Reference [***https://git.kernel.org/stable/c/7eb95e0af5c9c2e6fad50356eaf32d216d0e7bc3***](https://git.kernel.org/stable/c/7eb95e0af5c9c2e6fad50356eaf32d216d0e7bc3) [***https://git.kernel.org/stable/c/d4d1e4b1513d975961de7bb4f75e450a92d65ebf***](https://git.kernel.org/stable/c/d4d1e4b1513d975961de7bb4f75e450a92d65ebf) [***https://git.kernel.org/stable/c/5da6d306f315344af1ca2eff4bd9b10b130f0c28***](https://git.kernel.org/stable/c/5da6d306f315344af1ca2eff4bd9b10b130f0c28) [***https://git.kernel.org/stable/c/09a3c1e46142199adcee372a420b024b4fc61051***](https://git.kernel.org/stable/c/09a3c1e46142199adcee372a420b024b4fc61051)