Look up another CVE · open CVE-2024-57999 in the interactive tracker
CVE-2024-57999
powerpc/pseries/iommu: IOMMU incorrectly marks MMIO range in DDW
Published 2025-02-27 (20 months ago) by the Linux kernel CNA. Subsystem arch/powerpc. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2024-57999 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | vulnerable | 6.1.190-1 | No fix published anywhere yet, neither in Debian nor upstream for the series bookworm tracks. Watch the Debian tracker page for this CVE. Advisories for bookworm have historically landed a median of 23 days after publication. |
| Debian 13trixie | fixed | 6.12.13-1 | Update the kernel and reboot. Fixed in 6.12.13-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 6.12.13-1 | Update the kernel and reboot. Fixed in 6.12.13-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 6.12.13-1 | Update the kernel and reboot. Fixed in 6.12.13-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
Power Hypervisor can possibily allocate MMIO window intersecting with Dynamic DMA Window (DDW) range, which is over 32-bit addressing. These MMIO pages needs to be marked as reserved so that IOMMU doesn't map DMA buffers in this range. The current code is not marking these pages correctly which is resulting in LPAR to OOPS while booting. The stack is at below BUG: Unable to handle kernel data access on read at 0xc00800005cd40000 Faulting instruction address: 0xc00000000005cdac Oops: Kernel access of bad area, sig: 11 [#1] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries Modules linked in: af_packet rfkill ibmveth(X) lpfc(+) nvmet_fc nvmet nvme_keyring crct10dif_vpmsum nvme_fc nvme_fabrics nvme_core be2net(+) nvme_auth rtc_generic nfsd auth_rpcgss nfs_acl lockd grace sunrpc fuse configfs ip_tables x_tables xfs libcrc32c dm_service_time ibmvfc(X) scsi_transport_fc vmx_crypto gf128mul crc32c_vpmsum dm_mirror dm_region_hash dm_log dm_multipath dm_mod sd_mod scsi_dh_emc scsi_dh_rdac scsi_dh_alua t10_pi crc64_rocksoft_generic crc64_rocksoft sg crc64 scsi_mod Supported: Yes, External CPU: 8 PID: 241 Comm: kworker/8:1 Kdump: loaded Not tainted 6.4.0-150600.23.14-default #1 SLE15-SP6 b44ee71c81261b9e4bab5e0cde1f2ed891d5359b Hardware name: IBM,9080-M9S POWER9 (raw) 0x4e2103 0xf000005 of:IBM,FW950.B0 (VH950_149) hv:phyp pSeries Workqueue: events work_for_cpu_fn NIP: c00000000005cdac LR: c00000000005e830 CTR: 0000000000000000 REGS: c00001400c9ff770 TRAP: 0300 Not tainted (6.4.0-150600.23.14-default) MSR: 800000000280b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE> CR: 24228448 XER: 00000001 CFAR: c00000000005cdd4 DAR: c00800005cd40000 DSISR: 40000000 IRQMASK: 0 GPR00: c00000000005e830 c00001400c9ffa10 c000000001987d00 c00001400c4fe800 GPR04: 0000080000000000 0000000000000001 0000000004000000 0000000000800000 GPR08: 0000000004000000 0000000000000001 c00800005cd40000 ffffffffffffffff GPR12: 0000000084228882 c00000000a4c4f00 0000000000000010 0000080000000000 GPR16: c00001400c4fe800 0000000004000000 0800000000000000 c00000006088b800 GPR20: c00001401a7be980 c00001400eff3800 c000000002a2da68 000000000000002b GPR24: c0000000026793a8 c000000002679368 000000000000002a c0000000026793c8 GPR28: 000008007effffff 0000080000000000 0000000000800000 c00001400c4fe800 NIP [c00000000005cdac] iommu_table_reserve_pages+0xac/0x100 LR [c00000000005e830] iommu_init_table+0x80/0x1e0 Call Trace: [c00001400c9ffa10] [c00000000005e810] iommu_init_table+0x60/0x1e0 (unreliable) [c00001400c9ffa90] [c00000000010356c] iommu_bypass_supported_pSeriesLP+0x9cc/0xe40 [c00001400c9ffc30] [c00000000005c300] dma_iommu_dma_supported+0xf0/0x230 [c00001400c9ffcb0] [c00000000024b0c4] dma_supported+0x44/0x90 [c00001400c9ffcd0] [c00000000024b14c] dma_set_mask+0x3c/0x80 [c00001400c9ffd00] [c0080000555b715c] be_probe+0xc4/0xb90 [be2net] [c00001400c9ffdc0] [c000000000986f3c] local_pci_probe+0x6c/0x110 [c00001400c9ffe40] [c000000000188f28] work_for_cpu_fn+0x38/0x60 [c00001400c9ffe70] [c00000000018e454] process_one_work+0x314/0x620 [c00001400c9fff10] [c00000000018f280] worker_thread+0x2b0/0x620 [c00001400c9fff90] [c00000000019bb18] kthread+0x148/0x150 [c00001400c9fffe0] [c00000000000ded8] start_kernel_thread+0x14/0x18 There are 2 issues in the code 1. The index is "int" while the address is "unsigned long". This results in negative value when setting the bitmap. 2. The DMA offset is page shifted but the MMIO range is used as-is (64-bit address). MMIO address needs to be page shifted as well.
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
arch/powerpc/kernel/iommu.c
arch/powerpc/platforms/pseries/iommu.c
- What this is
- LINUX FOR POWERPC (32-BIT AND 64-BIT)MAINTAINERS section matched on arch/powerpc/ · linuxppc-dev@lists.ozlabs.org · Supported
Check it on the machine
grep -w CONFIG_PPC64 /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
Show whether Debian builds this, per release
Debian builds this, but not on every flavour. At least one release below builds the code on some of its kernel flavours and not on others, so the answer depends on the architecture and flavour installed.
- bookwormYnot built on amd64/amd64, amd64/cloud-amd64, amd64/rt/amd64, arm64/arm64, arm64/cloud-arm64, arm64/rt/arm64, armhf/armmp, armhf/armmp-lpae, armhf/rt/armmp, i386/686, i386/686-pae, i386/rt/686-pae
- trixieYnot built on amd64/amd64, amd64/cloud-amd64, amd64/rt/amd64, arm64/arm64, arm64/arm64-16k, arm64/cloud-arm64, arm64/rt/arm64, armel/rpi, armhf/armmp, armhf/armmp-lpae, armhf/rt/armmp, riscv64/riscv64, s390x/s390x
- forky, sidYnot built on amd64/amd64, amd64/cloud-amd64, amd64/rt-amd64, arm64/arm64, arm64/arm64-16k, arm64/cloud-arm64, arm64/rt-arm64, armhf/armmp, armhf/armmp-lpae, loong64/loong64, riscv64/riscv64, s390x/s390x
- Y
- built in where it is built at all; some flavours do not build it
- Build switch
- CONFIG_PPC64
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2025-02-27 (20 months ago)source
- CVSS
- 8.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.23%, higher than 13.0% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- arch/powerpc
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 5.15 | 6.12.13 | 7043d58ecd13 |
| 5.15 | 6.13.2 | d8cc20a8cceb |
| 5.15 | 6.14 | 8f70caad82e9 |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:LAttack vector, local
- The vulnerable code is powerpc/pseries platform IOMMU setup, reached either at local PCI driver probe (dma_set_mask → enable_ddw) or via the local VFIO SPAPR TCE container ioctl VFIO_IOMMU_SPAPR_TCE_CREATE. There is no network-facing path to iommu_init_table().
- AC:LAttack complexity, low
- Via the VFIO path the attacker directly supplies page_shift and window_size, which set it_offset = win_addr >> page_shift and it_size — the exact terms in the overlap test that decides whether the corrupt loop executes — and can enumerate the hypervisor-supported page sizes to force the overlap. On a given machine the DDW and MMIO32 base addresses are deterministic, so the trigger is repeatable.
- PR:LPrivileges required, low
- Exploitation requires only local access to a VFIO container and group fd, which is exactly what unprivileged device-passthrough processes (QEMU, userspace drivers) are granted by administrators; no root in the init namespace is needed. The boot/probe manifestation requires no attacker privileges at all.
- UI:NUser interaction, none
- The ioctl sequence is issued entirely by the attacker's own process, and the probe-path manifestation occurs autonomously during device initialization. No victim action is involved.
- S:CScope, changed
- The reserved-page mechanism exists specifically to stop the IOMMU from mapping DMA buffers over hypervisor-allocated MMIO ranges, so the mis-marking is a failure of the DMA/IOMMU isolation boundary itself, allowing device DMA to reach MMIO registers. On the VFIO path the corruption is driven from a guest/passthrough domain into host kernel state, crossing the VM boundary.
- C:HConfidentiality impact, high
- The truncated index makes set_bit() perform an out-of-bounds atomic read-modify-write far outside the vmalloc'd bitmap, and the poisoned it_reserved_start later drives find_next_bit() past the bitmap end in iommu_table_in_use(); combined with DMA/MMIO aliasing exposing hardware register contents, this is an unbounded out-of-bounds read.
- I:HIntegrity impact, high
- set_bit() at index 0xfffff80000000000 is an out-of-bounds write, attempted ~0x800000 times over an attacker-influenced range, giving an atomic bit-set primitive at wild kernel offsets. Additionally, DMA buffers mapped over the unreserved MMIO range write attacker-influenced data directly into hardware registers.
- A:HAvailability impact, high
- The reported and confirmed outcome is a kernel oops ("Kernel access of bad area, sig: 11") in iommu_table_reserve_pages() that kills the LPAR during boot or device probe. The VFIO path lets this be triggered on demand against a running host.