CVE-2026-64302: Linux Kernel Privilege Escalation Flaw

CVE-2026-64302 Overview

CVE-2026-64302 is a memory leak vulnerability in the Linux kernel's x86/mm subsystem. The flaw stems from commit bf9e4e30f353 ("x86/mm: use pagetable_free()"), which switched non-boot page table freeing from __free_pages() to pagetable_free(). The same code path also handles vmemmap pages, which are not page tables and not compound allocations. As a result, only the first page of a PMD-sized vmemmap allocation is released, leaking the remaining pages on memory hot-remove operations.

Critical Impact
Repeated memory hot-remove operations progressively leak PMD-sized vmemmap pages, degrading available kernel memory over time on affected x86 systems.

Affected Products

Linux kernel branches containing commit bf9e4e30f353 ("x86/mm: use pagetable_free()")
x86 architectures using PMD-sized vmemmap mappings
Kernel builds without the Hugetlb Vmemmap Optimization (HVO) path applied to affected allocations

Discovery Timeline

2026-07-25 - CVE-2026-64302 published to NVD
2026-07-25 - Last updated in NVD database

Technical Details for CVE-2026-64302

Vulnerability Analysis

The Linux kernel maintains a virtual memory map (vmemmap) that provides struct page entries for physical memory. On x86, vmemmap regions can be backed by PMD-sized (2 MiB) mappings for efficiency. When memory is hot-removed, the kernel must free both the page tables that map the vmemmap and the vmemmap pages themselves.

Commit bf9e4e30f353 unified the freeing path through pagetable_free(). That function internally calls __free_pages(page, compound_order(page)) and treats the page as a page table descriptor via page_ptdesc(page). Vmemmap pages allocated by vmemmap_alloc_block() are not compound pages and are not page tables, so compound_order() returns zero. Only the first 4 KiB of a 2 MiB vmemmap allocation is freed, leaving the remaining pages orphaned in the buddy allocator's accounting.

Root Cause

The root cause is an incorrect coupling of two distinct freeing paths inside free_pagetable(). Page tables and vmemmap pages have different allocation semantics, but the refactor applied pagetable_free() to both. Because vmemmap pages lack a compound page head, the order argument passed to __free_pages() is wrong, and the page_ptdesc() conversion is semantically invalid.

Attack Vector

The defect is triggered by legitimate kernel operations that call into the memory hot-remove path, including remove_pmd_table(). The vulnerability is a resource exhaustion condition rather than a directly exploitable memory-safety flaw. Repeated hot-plug or hot-remove cycles progressively reduce kernel memory availability. No verified proof-of-concept exploit or public exploit code is available at this time; see the upstream fixes for full technical detail.

Detection Methods for CVE-2026-64302

Indicators of Compromise

Steady decline in MemFree and MemAvailable values in /proc/meminfo on hosts that perform memory hot-plug operations.
Growth in unreclaimable kernel memory reported by /proc/vmstat counters after repeated hot-remove cycles.
Warnings or unusual buddy allocator behavior in dmesg around remove_pmd_table and vmemmap_free code paths.

Detection Strategies

Inventory hosts running kernels that include commit bf9e4e30f353 but lack fix commits 03f6ecb, 39406c0, or add1e41.
Correlate memory hot-plug events with subsequent kernel memory accounting anomalies to identify affected systems.
Track kernel version and patch level across the fleet to flag hosts that have not consumed the stable backport.

Monitoring Recommendations

Alert on progressive kernel memory reduction on virtualization hosts, cloud hypervisors, and bare-metal servers that use memory hot-plug.
Monitor NR_MEMMAP and slab counters over time on long-running x86 hosts.
Log kernel version and boot-time configuration to a central data store for patch compliance reporting.

How to Mitigate CVE-2026-64302

Immediate Actions Required

Identify all x86 Linux hosts running kernel versions containing commit bf9e4e30f353 without the corresponding fix.
Apply the upstream stable kernel patches: Kernel Git Patch 03f6ecb, Kernel Git Patch 39406c0, and Kernel Git Patch add1e41.
Prioritize patching on systems that regularly execute memory hot-plug or hot-remove operations, such as virtualization hosts and cloud infrastructure nodes.

Patch Information

The fix decouples page table freeing from vmemmap page freeing. free_pagetable() no longer manipulates SECTION_INFO, as only vmemmap is marked that way in register_page_bootmem_memmap(). The indentation in remove_pmd_table() is corrected as part of the same change. Distribution vendors are expected to backport the fix to supported long-term stable kernel branches; consult your distribution's security advisory feed for package versions.

Workarounds

Avoid memory hot-remove operations on unpatched hosts until the fixed kernel is deployed.
Reboot affected systems periodically to reclaim leaked vmemmap pages until patching is complete.
Where feasible, disable dynamic memory hot-plug in hypervisor guest configuration to prevent triggering the leaking code path.

bash

# Verify installed kernel version and check for the fix
uname -r
# On Debian/Ubuntu: check for updated kernel package
apt list --installed 2>/dev/null | grep linux-image
# On RHEL/Fedora: check for updated kernel package
rpm -qa | grep '^kernel-'
# Inspect memory hot-plug state
ls /sys/devices/system/memory/ | head