CVE-2026-89961: powerpc/mm: fix wrong addr_pfn tracking in compound vmemmap population
In the Linux kernel, the following vulnerability has been resolved:
powerpc/mm: fix wrong addrpfn tracking in compound vmemmap population
vmemmappopulatecompoundpages() uses addrpfn 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, addrpfn is advanced manually in parallel with addr. The loop itself progresses in vmemmap address space, so each PAGESIZE step in addr covers PAGESIZE / sizeof(struct page) struct page slots. Since addrpfn is compared against nrpages 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, pfnoffset 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 addrpfn directly from the current vmemmap address instead of carrying it as loop state.
Event History
Frequently Asked Questions
Which systems are affected?
The issue is in the Linux kernel powerpc memory-management code, specifically compound vmemmap population. The provided information does not identify affected kernel versions or configurations.
What is the practical impact of the faulty tracking?
The code can calculate a PFN offset using the wrong PFN and make the head-page versus tail-page mapping decision for the wrong position within a compound page. The provided information does not describe a security impact, exploit method, or required attacker access.
How can I determine whether a fix is available in my kernel source tree?
Check whether the powerpc/mm compound vmemmap population code derives addr_pfn directly from the current vmemmap address rather than manually advancing addr_pfn alongside addr. The listed stable references identify commits containing the resolution.