CVE-2024-26745

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: powerpc/pseries/iommu: la tabla IOMMU no está inicializada para kdump sobre SR-IOV Cuando el kernel de kdump intenta copiar datos de volcado sobre SR-IOV, LPAR entra en pánico debido a una excepción de puntero NULL: El kernel intentó leer la página del usuario (0): ¿intento de explotación? (uid: 0) ERROR: Desreferencia del puntero NULL del kernel al leer en0x00000000 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. En el momento del volcado de LPAR, antes de que kexec entregue el control al kernel de kdump, los DDW (Dynamic DMA Windows) se escanean y agregan al FDT. Para el caso de SR-IOV, la ventana DMA predeterminada "ibm,dma-window" se elimina de FDT y se agrega DDW para el dispositivo. Ahora, kexec entrega el control al kernel kdump. Cuando se inicializa el kernel kdump, se escanean los buses PCI y se crean grupos/tablas IOMMU, en pci_dma_bus_setup_pSeriesLP(). Para el caso SR-IOV, no existe "ibm,dma-window". el commit original: b1fc44eaa9ba, corrige la ruta donde la memoria está preasignada (asignada directamente) al DDW. Cuando las TCE se asignan directamente, no es necesario inicializar las tablas IOMMU. iommu_table_setparms_lpar() solo considera la propiedad "ibm,dma-window" al inicializar la tabla IOMMU. En el escenario en el que las TCE se asignan dinámicamente para SR-IOV, la tabla IOMMU recién creada no se inicializa. Más tarde, cuando el controlador del dispositivo intenta ingresar TCE para el dispositivo SR-IOV, se genera una ejecución de puntero NULL desde iommu_area_alloc(). La solución es inicializar la tabla IOMMU con la propiedad DDW almacenada en el FDT. Hay 2 puntos para recordar: 1. Para el adaptador dedicado, el kernel de kdump encontraría tanto el valor predeterminado como el DDW en FDT. En este caso, la propiedad DDW se utiliza para inicializar la tabla IOMMU. 2. Un DDW podría tener un mapeo directo o dinámico. El kernel kdump inicializaría la tabla IOMMU y marcaría el DDW existente como "dinámico". Esto funciona bien ya que, en el momento de la inicialización de la tabla, iommu_table_clear() crea algo de espacio en el DDW, para una cantidad predefinida de TCE que son necesarias para que kdump tenga éxito.