Look up another CVE · open CVE-2026-89961 in the interactive tracker
CVE-2026-89961
powerpc/mm: fix wrong addr_pfn tracking in compound vmemmap population
Published 2026-09-16 (33 days ago) by the Linux kernel CNA. Subsystem arch/powerpc. Debian urgency: unimportant.
What to do, per Debian release
Debian's own status for CVE-2026-89961 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 | not affected | 6.1.190-1 | Nothing to do. bookworm never shipped the vulnerable code. |
| Debian 13trixie | fixedDSA-6528-1 · 2026-09-29 · text | 6.12.111-1 | Update the kernel and reboot. DSA-6528-1 shipped the fix on 2026-09-29, in 6.12.111-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian 12bookworm · linux-6.12 | fixedDLA-4817-1 · 2026-10-04 · text | 6.12.111-1~deb12u1 | Update the kernel and reboot. DLA-4817-1 shipped the fix on 2026-10-04, in 6.12.111-1~deb12u1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
vmemmap_populate_compound_pages() uses addr_pfn to determine the PFN offset within a compound page and to decide whether the current vmemmap slot should be populated as a head page mapping or should reuse a tail page mapping. However, addr_pfn is advanced manually in parallel with addr. The loop itself progresses in vmemmap address space, so each PAGE_SIZE step in addr covers PAGE_SIZE / sizeof(struct page) struct page slots. Since addr_pfn is compared against nr_pages in data-PFN units, it should advance by the same number of PFNs. The existing manual increments do not match that and therefore do not reliably track the PFN corresponding to the current addr. As a result, pfn_offset can be computed from the wrong PFN and the code can make the head/tail decision for the wrong compound-page position. Fix this by deriving addr_pfn directly from the current vmemmap address instead of carrying it as loop state.
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/mm/book3s64/radix_pgtable.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 -wE 'CONFIG_PPC_BOOK3S_64|CONFIG_PPC_RADIX_MMU' /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
- bookworm · linux-6.12Ynot 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, armhf/rt/armmp
- Y
- built in where it is built at all; some flavours do not build it
- Build switches
- CONFIG_PPC_BOOK3S_64, CONFIG_PPC_RADIX_MMU
- Reads as
- all on means the file is compiled; any one off means it is not.
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
- 2026-09-16 (33 days ago)source
- CVSS
- 7.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.18%, higher than 6.6% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- unimportantsource
- 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 |
|---|---|---|
| 6.6 | 6.6.157 | b96be860673f |
| 6.6 | 6.12.110 | e163c7184acf |
| 6.6 | 6.18.51 | 9c914b7a0bd1 |
| 6.6 | 7.2.5 | 7968852a7ca3 |
| 6.6 | 7.3 | 89a4ae327641 |
Debian advisories
| Advisory | Date | Shipped to | Debian |
|---|---|---|---|
| DLA-4817-1 | 2026-10-04 | bookworm 6.12.111-1~deb12u1 | tracker |
| DSA-6528-1 | 2026-09-29 | trixie 6.12.111-1 | tracker |
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 bug is in powerpc radix vmemmap_populate_compound_pages(), reached only through local ZONE_DEVICE hotplug (dev_dax_probe → devm_memremap_pages → arch_add_memory → sparse_add_section). It is not reachable from network protocols, Bluetooth, or USB.
- AC:LAttack complexity, low
- Once device-DAX with compound vmemmap is mapped (2MB PMD on 4K kernels or 1GB PUD on 64K, the documented powerpc DAX configs), addr_pfn drifts on every loop iteration and the wrong head/tail mapping is deterministic; no race or attacker-uncontrollable layout is required.
- PR:LPrivileges required, low
- Initial memremap requires administrator DAX setup, but on a provisioned persistent-memory or cloud POWER server an unprivileged local user with /dev/dax access can mmap the device and drive kernel use of the mis-aliased struct pages via faults and GUP without init-namespace CAP_SYS_ADMIN.
- UI:NUser interaction, none
- Exploitation needs no victim action; the attacker mmaps or faults the already-provisioned DAX device themselves. No mount, click, or hotplug by another user is required at exploit time.
- S:UScope, unchanged
- Impact is kernel struct-page aliasing and MM corruption inside the same host kernel security authority. It is not a KVM guest-to-host escape, IOMMU/DMA bypass, or sandbox boundary crossing.
- C:HConfidentiality impact, high
- Wrong pfn_offset aliases distinct vmemmap pages so different DAX PFNs share struct-page backing; later memmap_init, faults, and GUP read corrupted flags, mapping, and compound-head fields, disclosing kernel memory via that metadata.
- I:HIntegrity impact, high
- The same aliases turn kernel writes (page init, folio mapping, refcount, compound head/tail linkage) into writes to the wrong struct pages, an exploitable kernel memory-corruption primitive that can hijack control flow rather than a bounded data modification.
- A:HAvailability impact, high
- Mis-linked compound pages and aliased vmemmap cause kernel oops, BUG_ON, or panic when MM code walks folio heads, refcounts, or DAX fault handlers, fully denying availability of the affected POWER radix host.