CVE-2026-64302: x86/mm: Fix freeing of PMD-sized vmemmap pages
In the Linux kernel, the following vulnerability has been resolved:
x86/mm: Fix freeing of PMD-sized vmemmap pages
Commit bf9e4e30f353 ("x86/mm: use pagetablefree()"), switched from freeing non-boot page tables through freepages() to pagetablefree().
However, the function is also called to free vmemmap pages.
Given that vmemmap pages are not page tables, already the pageptdesc(page) is wrong. But worse, pagetablefree() calls:
freepages(page, compoundorder(page));
Since vmemmap pages are not compound pages (see vmemmapallocblock()) -- except for HVO, which doesn't apply here -- only first page of a PMD-sized vmemmap page is freed, leaking the other ones.
Fix it by properly decoupling pagetable and vmemmap freeing. freepagetable() no longer has to mess with SECTIONINFO, as only the vmemmap is marked like that in registerpagebootmemmemmap().
The indentation in removepmdtable() is messed up. Fix that while touching it.
Bootmem info handling will soon be fixed up. For now, handle it similar to freepagetable(), just avoiding the ifdef.
[ dhansen: changelog munging. More imperative voice ]
Affected Software
Remediation
Event History
Frequently Asked Questions
What conditions are required for this issue to have an effect?
The affected code path must free PMD-sized vmemmap pages. The problem arises because those pages are passed to pagetable_free() even though they are not page tables or compound pages.
What is the practical impact of the bug?
When a PMD-sized vmemmap page is freed, only its first page may be released. The remaining pages are leaked, causing an availability impact through kernel memory leakage.
Is a fix available?
Yes. A patch is available through the listed stable Linux kernel commits, which decouple page-table freeing from vmemmap-page freeing.