CVE-2026-89961
largeLocal memory-corruption flaw in Linux kernel PowerPC compound vmemmap population
The Linux kernel's PowerPC memory-management code incorrectly tracks the PFN (addr_pfn) while populating vmemmap mappings for compound pages: the manual increments of addr_pfn do not match the number of struct-page slots covered by each vmemmap step, so the kernel can compute pfn_offset from the wrong PFN and map a head-page or tail-page slot at the wrong compound-page position. The flaw is triggered locally when a PowerPC (powerpc64) kernel populates compound vmemmap, for example during memory hotplug/device DAX-style mapping of large compound pages. Successful triggering corrupts struct-page mappings, which the CVSS scores as high impact to confidentiality, integrity and availability — plausibly a route to kernel memory corruption, crashes, or local privilege escalation by an attacker with low privileges. Only Linux systems running PowerPC builds that include the affected vmemmap_populate_compound_pages() code path are affected; x86 and ARM systems are not. No public proof-of-concept or known in-the-wild exploitation exists, and the issue is not in CISA's KEV catalog.
What to do: Update PowerPC (ppc64le) systems to a kernel that includes the upstream fix, which derives addr_pfn directly from the current vmemmap address, as shipped/backported in the distro or stable kernel branches you follow. Check whether POWER-based hosts run recent kernels with memory hotplug or device DAX and compound-page vmemmap support, and restrict local untrusted accounts on such hosts until patched. Watch for kernel oopses or memory-corruption symptoms on PowerPC machines as an indicator of the bug being hit.
| Linux kernel — PowerPC (powerpc64) architecture builds with compound vmemmap population (vmemmap_populate_compound_pages | — |
Order-of-magnitude estimate by the model from install counts, market share and public scan data it knows; verify before quoting.
In the Linux kernel, the following vulnerability has been resolved: powerpc/mm: fix wrong addr_pfn tracking in compound vmemmap population 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.
- Vector
- CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
In the news0 stories
No ingested article mentions this CVE yet.