{
  "gsd": {
    "metadata": {
      "exploitCode": "unknown",
      "remediation": "unknown",
      "reportConfidence": "confirmed",
      "type": "vulnerability"
    },
    "osvSchema": {
      "aliases": [
        "CVE-2024-26745"
      ],
      "details": "In the Linux kernel, the following vulnerability has been resolved:\n\npowerpc/pseries/iommu: IOMMU table is not initialized for kdump over SR-IOV\n\nWhen kdump kernel tries to copy dump data over SR-IOV, LPAR panics due\nto NULL pointer exception:\n\n  Kernel attempted to read user page (0) - exploit attempt? (uid: 0)\n  BUG: Kernel NULL pointer dereference on read at 0x00000000\n  Faulting instruction address: 0xc000000020847ad4\n  Oops: Kernel access of bad area, sig: 11 [#1]\n  LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries\n  Modules linked in: mlx5_core(+) vmx_crypto pseries_wdt papr_scm libnvdimm mlxfw tls psample sunrpc fuse overlay squashfs loop\n  CPU: 12 PID: 315 Comm: systemd-udevd Not tainted 6.4.0-Test102+ #12\n  Hardware name: IBM,9080-HEX POWER10 (raw) 0x800200 0xf000006 of:IBM,FW1060.00 (NH1060_008) hv:phyp pSeries\n  NIP:  c000000020847ad4 LR: c00000002083b2dc CTR: 00000000006cd18c\n  REGS: c000000029162ca0 TRAP: 0300   Not tainted  (6.4.0-Test102+)\n  MSR:  800000000280b033 \u003cSF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE\u003e  CR: 48288244  XER: 00000008\n  CFAR: c00000002083b2d8 DAR: 0000000000000000 DSISR: 40000000 IRQMASK: 1\n  ...\n  NIP _find_next_zero_bit+0x24/0x110\n  LR  bitmap_find_next_zero_area_off+0x5c/0xe0\n  Call Trace:\n    dev_printk_emit+0x38/0x48 (unreliable)\n    iommu_area_alloc+0xc4/0x180\n    iommu_range_alloc+0x1e8/0x580\n    iommu_alloc+0x60/0x130\n    iommu_alloc_coherent+0x158/0x2b0\n    dma_iommu_alloc_coherent+0x3c/0x50\n    dma_alloc_attrs+0x170/0x1f0\n    mlx5_cmd_init+0xc0/0x760 [mlx5_core]\n    mlx5_function_setup+0xf0/0x510 [mlx5_core]\n    mlx5_init_one+0x84/0x210 [mlx5_core]\n    probe_one+0x118/0x2c0 [mlx5_core]\n    local_pci_probe+0x68/0x110\n    pci_call_probe+0x68/0x200\n    pci_device_probe+0xbc/0x1a0\n    really_probe+0x104/0x540\n    __driver_probe_device+0xb4/0x230\n    driver_probe_device+0x54/0x130\n    __driver_attach+0x158/0x2b0\n    bus_for_each_dev+0xa8/0x130\n    driver_attach+0x34/0x50\n    bus_add_driver+0x16c/0x300\n    driver_register+0xa4/0x1b0\n    __pci_register_driver+0x68/0x80\n    mlx5_init+0xb8/0x100 [mlx5_core]\n    do_one_initcall+0x60/0x300\n    do_init_module+0x7c/0x2b0\n\nAt the time of LPAR dump, before kexec hands over control to kdump\nkernel, DDWs (Dynamic DMA Windows) are scanned and added to the FDT.\nFor the SR-IOV case, default DMA window \"ibm,dma-window\" is removed from\nthe FDT and DDW added, for the device.\n\nNow, kexec hands over control to the kdump kernel.\n\nWhen the kdump kernel initializes, PCI busses are scanned and IOMMU\ngroup/tables created, in pci_dma_bus_setup_pSeriesLP(). For the SR-IOV\ncase, there is no \"ibm,dma-window\". The original commit: b1fc44eaa9ba,\nfixes the path where memory is pre-mapped (direct mapped) to the DDW.\nWhen TCEs are direct mapped, there is no need to initialize IOMMU\ntables.\n\niommu_table_setparms_lpar() only considers \"ibm,dma-window\" property\nwhen initiallizing IOMMU table. In the scenario where TCEs are\ndynamically allocated for SR-IOV, newly created IOMMU table is not\ninitialized. Later, when the device driver tries to enter TCEs for the\nSR-IOV device, NULL pointer execption is thrown from iommu_area_alloc().\n\nThe fix is to initialize the IOMMU table with DDW property stored in the\nFDT. There are 2 points to remember:\n\n\t1. For the dedicated adapter, kdump kernel would encounter both\n\t   default and DDW in FDT. In this case, DDW property is used to\n\t   initialize the IOMMU table.\n\n\t2. A DDW could be direct or dynamic mapped. kdump kernel would\n\t   initialize IOMMU table and mark the existing DDW as\n\t   \"dynamic\". This works fine since, at the time of table\n\t   initialization, iommu_table_clear() makes some space in the\n\t   DDW, for some predefined number of TCEs which are needed for\n\t   kdump to succeed.",
      "id": "GSD-2024-26745",
      "modified": "2024-02-20T06:02:29.120902Z",
      "schema_version": "1.4.0"
    }
  },
  "namespaces": {
    "cve.org": {
      "CVE_data_meta": {
        "ASSIGNER": "cve@kernel.org",
        "ID": "CVE-2024-26745",
        "STATE": "PUBLIC"
      },
      "affects": {
        "vendor": {
          "vendor_data": [
            {
              "product": {
                "product_data": [
                  {
                    "product_name": "Linux",
                    "version": {
                      "version_data": [
                        {
                          "version_affected": "\u003c",
                          "version_name": "b1fc44eaa9ba",
                          "version_value": "7eb95e0af5c9"
                        },
                        {
                          "version_value": "not down converted",
                          "x_cve_json_5_version_data": {
                            "defaultStatus": "affected",
                            "versions": [
                              {
                                "status": "affected",
                                "version": "6.0"
                              },
                              {
                                "lessThan": "6.0",
                                "status": "unaffected",
                                "version": "0",
                                "versionType": "custom"
                              },
                              {
                                "lessThanOrEqual": "6.1.*",
                                "status": "unaffected",
                                "version": "6.1.81",
                                "versionType": "custom"
                              },
                              {
                                "lessThanOrEqual": "6.6.*",
                                "status": "unaffected",
                                "version": "6.6.21",
                                "versionType": "custom"
                              },
                              {
                                "lessThanOrEqual": "6.7.*",
                                "status": "unaffected",
                                "version": "6.7.9",
                                "versionType": "custom"
                              },
                              {
                                "lessThanOrEqual": "*",
                                "status": "unaffected",
                                "version": "6.8",
                                "versionType": "original_commit_for_fix"
                              }
                            ]
                          }
                        }
                      ]
                    }
                  }
                ]
              },
              "vendor_name": "Linux"
            }
          ]
        }
      },
      "data_format": "MITRE",
      "data_type": "CVE",
      "data_version": "4.0",
      "description": {
        "description_data": [
          {
            "lang": "eng",
            "value": "In the Linux kernel, the following vulnerability has been resolved:\n\npowerpc/pseries/iommu: IOMMU table is not initialized for kdump over SR-IOV\n\nWhen kdump kernel tries to copy dump data over SR-IOV, LPAR panics due\nto NULL pointer exception:\n\n  Kernel attempted to read user page (0) - exploit attempt? (uid: 0)\n  BUG: Kernel NULL pointer dereference on read at 0x00000000\n  Faulting instruction address: 0xc000000020847ad4\n  Oops: Kernel access of bad area, sig: 11 [#1]\n  LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries\n  Modules linked in: mlx5_core(+) vmx_crypto pseries_wdt papr_scm libnvdimm mlxfw tls psample sunrpc fuse overlay squashfs loop\n  CPU: 12 PID: 315 Comm: systemd-udevd Not tainted 6.4.0-Test102+ #12\n  Hardware name: IBM,9080-HEX POWER10 (raw) 0x800200 0xf000006 of:IBM,FW1060.00 (NH1060_008) hv:phyp pSeries\n  NIP:  c000000020847ad4 LR: c00000002083b2dc CTR: 00000000006cd18c\n  REGS: c000000029162ca0 TRAP: 0300   Not tainted  (6.4.0-Test102+)\n  MSR:  800000000280b033 \u003cSF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE\u003e  CR: 48288244  XER: 00000008\n  CFAR: c00000002083b2d8 DAR: 0000000000000000 DSISR: 40000000 IRQMASK: 1\n  ...\n  NIP _find_next_zero_bit+0x24/0x110\n  LR  bitmap_find_next_zero_area_off+0x5c/0xe0\n  Call Trace:\n    dev_printk_emit+0x38/0x48 (unreliable)\n    iommu_area_alloc+0xc4/0x180\n    iommu_range_alloc+0x1e8/0x580\n    iommu_alloc+0x60/0x130\n    iommu_alloc_coherent+0x158/0x2b0\n    dma_iommu_alloc_coherent+0x3c/0x50\n    dma_alloc_attrs+0x170/0x1f0\n    mlx5_cmd_init+0xc0/0x760 [mlx5_core]\n    mlx5_function_setup+0xf0/0x510 [mlx5_core]\n    mlx5_init_one+0x84/0x210 [mlx5_core]\n    probe_one+0x118/0x2c0 [mlx5_core]\n    local_pci_probe+0x68/0x110\n    pci_call_probe+0x68/0x200\n    pci_device_probe+0xbc/0x1a0\n    really_probe+0x104/0x540\n    __driver_probe_device+0xb4/0x230\n    driver_probe_device+0x54/0x130\n    __driver_attach+0x158/0x2b0\n    bus_for_each_dev+0xa8/0x130\n    driver_attach+0x34/0x50\n    bus_add_driver+0x16c/0x300\n    driver_register+0xa4/0x1b0\n    __pci_register_driver+0x68/0x80\n    mlx5_init+0xb8/0x100 [mlx5_core]\n    do_one_initcall+0x60/0x300\n    do_init_module+0x7c/0x2b0\n\nAt the time of LPAR dump, before kexec hands over control to kdump\nkernel, DDWs (Dynamic DMA Windows) are scanned and added to the FDT.\nFor the SR-IOV case, default DMA window \"ibm,dma-window\" is removed from\nthe FDT and DDW added, for the device.\n\nNow, kexec hands over control to the kdump kernel.\n\nWhen the kdump kernel initializes, PCI busses are scanned and IOMMU\ngroup/tables created, in pci_dma_bus_setup_pSeriesLP(). For the SR-IOV\ncase, there is no \"ibm,dma-window\". The original commit: b1fc44eaa9ba,\nfixes the path where memory is pre-mapped (direct mapped) to the DDW.\nWhen TCEs are direct mapped, there is no need to initialize IOMMU\ntables.\n\niommu_table_setparms_lpar() only considers \"ibm,dma-window\" property\nwhen initiallizing IOMMU table. In the scenario where TCEs are\ndynamically allocated for SR-IOV, newly created IOMMU table is not\ninitialized. Later, when the device driver tries to enter TCEs for the\nSR-IOV device, NULL pointer execption is thrown from iommu_area_alloc().\n\nThe fix is to initialize the IOMMU table with DDW property stored in the\nFDT. There are 2 points to remember:\n\n\t1. For the dedicated adapter, kdump kernel would encounter both\n\t   default and DDW in FDT. In this case, DDW property is used to\n\t   initialize the IOMMU table.\n\n\t2. A DDW could be direct or dynamic mapped. kdump kernel would\n\t   initialize IOMMU table and mark the existing DDW as\n\t   \"dynamic\". This works fine since, at the time of table\n\t   initialization, iommu_table_clear() makes some space in the\n\t   DDW, for some predefined number of TCEs which are needed for\n\t   kdump to succeed."
          }
        ]
      },
      "generator": {
        "engine": "bippy-e0c11145c45e"
      },
      "problemtype": {
        "problemtype_data": [
          {
            "description": [
              {
                "lang": "eng",
                "value": "n/a"
              }
            ]
          }
        ]
      },
      "references": {
        "reference_data": [
          {
            "name": "https://git.kernel.org/stable/c/7eb95e0af5c9c2e6fad50356eaf32d216d0e7bc3",
            "refsource": "MISC",
            "url": "https://git.kernel.org/stable/c/7eb95e0af5c9c2e6fad50356eaf32d216d0e7bc3"
          },
          {
            "name": "https://git.kernel.org/stable/c/d4d1e4b1513d975961de7bb4f75e450a92d65ebf",
            "refsource": "MISC",
            "url": "https://git.kernel.org/stable/c/d4d1e4b1513d975961de7bb4f75e450a92d65ebf"
          },
          {
            "name": "https://git.kernel.org/stable/c/5da6d306f315344af1ca2eff4bd9b10b130f0c28",
            "refsource": "MISC",
            "url": "https://git.kernel.org/stable/c/5da6d306f315344af1ca2eff4bd9b10b130f0c28"
          },
          {
            "name": "https://git.kernel.org/stable/c/09a3c1e46142199adcee372a420b024b4fc61051",
            "refsource": "MISC",
            "url": "https://git.kernel.org/stable/c/09a3c1e46142199adcee372a420b024b4fc61051"
          }
        ]
      }
    },
    "nvd.nist.gov": {
      "cve": {
        "descriptions": [
          {
            "lang": "en",
            "value": "In the Linux kernel, the following vulnerability has been resolved:\n\npowerpc/pseries/iommu: IOMMU table is not initialized for kdump over SR-IOV\n\nWhen kdump kernel tries to copy dump data over SR-IOV, LPAR panics due\nto NULL pointer exception:\n\n  Kernel attempted to read user page (0) - exploit attempt? (uid: 0)\n  BUG: Kernel NULL pointer dereference on read at 0x00000000\n  Faulting instruction address: 0xc000000020847ad4\n  Oops: Kernel access of bad area, sig: 11 [#1]\n  LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries\n  Modules linked in: mlx5_core(+) vmx_crypto pseries_wdt papr_scm libnvdimm mlxfw tls psample sunrpc fuse overlay squashfs loop\n  CPU: 12 PID: 315 Comm: systemd-udevd Not tainted 6.4.0-Test102+ #12\n  Hardware name: IBM,9080-HEX POWER10 (raw) 0x800200 0xf000006 of:IBM,FW1060.00 (NH1060_008) hv:phyp pSeries\n  NIP:  c000000020847ad4 LR: c00000002083b2dc CTR: 00000000006cd18c\n  REGS: c000000029162ca0 TRAP: 0300   Not tainted  (6.4.0-Test102+)\n  MSR:  800000000280b033 \u003cSF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE\u003e  CR: 48288244  XER: 00000008\n  CFAR: c00000002083b2d8 DAR: 0000000000000000 DSISR: 40000000 IRQMASK: 1\n  ...\n  NIP _find_next_zero_bit+0x24/0x110\n  LR  bitmap_find_next_zero_area_off+0x5c/0xe0\n  Call Trace:\n    dev_printk_emit+0x38/0x48 (unreliable)\n    iommu_area_alloc+0xc4/0x180\n    iommu_range_alloc+0x1e8/0x580\n    iommu_alloc+0x60/0x130\n    iommu_alloc_coherent+0x158/0x2b0\n    dma_iommu_alloc_coherent+0x3c/0x50\n    dma_alloc_attrs+0x170/0x1f0\n    mlx5_cmd_init+0xc0/0x760 [mlx5_core]\n    mlx5_function_setup+0xf0/0x510 [mlx5_core]\n    mlx5_init_one+0x84/0x210 [mlx5_core]\n    probe_one+0x118/0x2c0 [mlx5_core]\n    local_pci_probe+0x68/0x110\n    pci_call_probe+0x68/0x200\n    pci_device_probe+0xbc/0x1a0\n    really_probe+0x104/0x540\n    __driver_probe_device+0xb4/0x230\n    driver_probe_device+0x54/0x130\n    __driver_attach+0x158/0x2b0\n    bus_for_each_dev+0xa8/0x130\n    driver_attach+0x34/0x50\n    bus_add_driver+0x16c/0x300\n    driver_register+0xa4/0x1b0\n    __pci_register_driver+0x68/0x80\n    mlx5_init+0xb8/0x100 [mlx5_core]\n    do_one_initcall+0x60/0x300\n    do_init_module+0x7c/0x2b0\n\nAt the time of LPAR dump, before kexec hands over control to kdump\nkernel, DDWs (Dynamic DMA Windows) are scanned and added to the FDT.\nFor the SR-IOV case, default DMA window \"ibm,dma-window\" is removed from\nthe FDT and DDW added, for the device.\n\nNow, kexec hands over control to the kdump kernel.\n\nWhen the kdump kernel initializes, PCI busses are scanned and IOMMU\ngroup/tables created, in pci_dma_bus_setup_pSeriesLP(). For the SR-IOV\ncase, there is no \"ibm,dma-window\". The original commit: b1fc44eaa9ba,\nfixes the path where memory is pre-mapped (direct mapped) to the DDW.\nWhen TCEs are direct mapped, there is no need to initialize IOMMU\ntables.\n\niommu_table_setparms_lpar() only considers \"ibm,dma-window\" property\nwhen initiallizing IOMMU table. In the scenario where TCEs are\ndynamically allocated for SR-IOV, newly created IOMMU table is not\ninitialized. Later, when the device driver tries to enter TCEs for the\nSR-IOV device, NULL pointer execption is thrown from iommu_area_alloc().\n\nThe fix is to initialize the IOMMU table with DDW property stored in the\nFDT. There are 2 points to remember:\n\n\t1. For the dedicated adapter, kdump kernel would encounter both\n\t   default and DDW in FDT. In this case, DDW property is used to\n\t   initialize the IOMMU table.\n\n\t2. A DDW could be direct or dynamic mapped. kdump kernel would\n\t   initialize IOMMU table and mark the existing DDW as\n\t   \"dynamic\". This works fine since, at the time of table\n\t   initialization, iommu_table_clear() makes some space in the\n\t   DDW, for some predefined number of TCEs which are needed for\n\t   kdump to succeed."
          },
          {
            "lang": "es",
            "value": "En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: powerpc/pseries/iommu: la tabla IOMMU no est\u00e1 inicializada para kdump sobre SR-IOV Cuando el kernel de kdump intenta copiar datos de volcado sobre SR-IOV, LPAR entra en p\u00e1nico debido a una excepci\u00f3n de puntero NULL: El kernel intent\u00f3 leer la p\u00e1gina del usuario (0): \u00bfintento de explotaci\u00f3n? (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\u00e1 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\u00e1micamente para SR-IOV, la tabla IOMMU reci\u00e9n creada no se inicializa. M\u00e1s tarde, cuando el controlador del dispositivo intenta ingresar TCE para el dispositivo SR-IOV, se genera una ejecuci\u00f3n de puntero NULL desde iommu_area_alloc(). La soluci\u00f3n 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\u00eda 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\u00eda tener un mapeo directo o din\u00e1mico. El kernel kdump inicializar\u00eda la tabla IOMMU y marcar\u00eda el DDW existente como \"din\u00e1mico\". Esto funciona bien ya que, en el momento de la inicializaci\u00f3n 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 \u00e9xito."
          }
        ],
        "id": "CVE-2024-26745",
        "lastModified": "2024-04-04T12:48:41.700",
        "metrics": {},
        "published": "2024-04-04T09:15:07.713",
        "references": [
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "url": "https://git.kernel.org/stable/c/09a3c1e46142199adcee372a420b024b4fc61051"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "url": "https://git.kernel.org/stable/c/5da6d306f315344af1ca2eff4bd9b10b130f0c28"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "url": "https://git.kernel.org/stable/c/7eb95e0af5c9c2e6fad50356eaf32d216d0e7bc3"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "url": "https://git.kernel.org/stable/c/d4d1e4b1513d975961de7bb4f75e450a92d65ebf"
          }
        ],
        "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "vulnStatus": "Awaiting Analysis"
      }
    }
  }
}