CVE-2026-97525 in Linux
Summary
by MITRE • 09/25/2026
In the Linux kernel, the following vulnerability has been resolved:
x86/mm/pat: Allocate split page tables as kernel page tables
A PTE is allocated directly without going through the standard page table allocation routines (such as pte_alloc_one_kernel()) when the CPA code splits a large page (__split_large_page()).
This means the page table constructor is never called nor is the page table marked as a kernel page table.
The former results in the folio associated with the page table not being marked as a page table (__pagetable_ctor() is never called thus neither is __folio_set_pgtable()) nor are statistics updated to reflect it (lruvec_stat_add_folio() is never called).
The latter issue of failing to mark the page table as a kernel page table (ptdesc_set_kernel() is never called) is far more problematic.
Since commit:
5ba2f0a15564 ("mm: introduce deferred freeing for kernel page tables")
kernel page table freeing has been batched and since the subsequent commit:
e37d5a2d60a3 ("iommu/sva: invalidate stale IOTLB entries for kernel address space")
IOTLB cache entries for kernel page tables have been invalidated upon being freed.
Since split page tables are freed without this invalidation, the IOTLB can contain stale entries for them.
Resolve the issue by using the ordinary PTE allocation API at split time.
This results in these kernel page tables invoking a page table constructor, and thus requires a page table destructor.
Destructors are not always present, like for early allocated direct map page tables). Conditionally call pagetable_dtor_free() if the PG_table folio flag for the ptdesc is set, otherwise we free the page table via pagetable_free().
Regardless of which path is taken page tables marked as kernel page tables, which now includes split page tables, take the correct route through pagetable_free_kernel().
There is a user-visible side effect in that split page tables will appear in nr_page_table_pages in /proc/vmstat (as do other kernel page tables allocated after early boot), however this is a positive change.
This issue started being markedly problematic after commit:
5ba2f0a15564 ("mm: introduce deferred freeing for kernel page tables")
so choose this as the Fixes target.
[ dhansen: rephrase in imperative mood ]
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/25/2026
The Linux kernel contains a vulnerability within the x86 memory management subsystem, specifically in the Page Attribute Table (PAT) handling code responsible for splitting large pages into smaller page table entries. When the Copy-on-Write or similar mechanisms trigger the CPA code to split a large physical page via __split_large_page(), the system allocates new Page Table Entries directly without utilizing standard kernel page table allocation routines such as pte_alloc_one_kernel(). This bypass of the standard allocation path results in critical initialization steps being skipped, most notably the invocation of the page table constructor and the marking of the allocated memory as a kernel page table. The failure to call __pagetable_ctor() means that the folio associated with the new page table is not properly tagged as containing page tables, nor are internal statistics updated via lruvec_stat_add_folio(), leading to inaccurate accounting in /proc/vmstat where split page tables were previously invisible until this fix was applied.
The most severe consequence of this flaw stems from the failure to mark these dynamically allocated split page tables as kernel page tables using ptdesc_set_kernel(). Since commit 5ba2f0a15564 introduced deferred freeing for kernel page tables, and subsequently commit e37d5a2d60a3 added logic to invalidate stale Input Output Translation Lookaside Buffer entries upon the freeing of kernel address space pages, any page table freed without this designation escapes these safety mechanisms. Consequently, when a split page table is eventually reclaimed by the memory management subsystem, its associated IOTLB cache entries are not invalidated. This leaves stale mappings in the hardware translation lookaside buffer, which can lead to incorrect memory translations for devices performing direct memory access or other operations relying on accurate address translation data.
This vulnerability aligns with CWE-20 Improper Input Validation and CWE-754 Improper Check for Unusual or Exceptional Conditions, as the code fails to validate that all necessary initialization routines are executed during dynamic resource allocation under specific conditions. From an ATT&CK perspective, this flaw relates to T1620 Reflective Code Loading or potentially T1059 Command and Scripting Interpreter if exploited in conjunction with other vulnerabilities, but primarily it represents a memory management integrity issue (T1499 Endpoint Denial of Service) due to the potential for IOTLB corruption causing system instability. The stale entries could theoretically be leveraged by an attacker who has gained kernel-level execution privileges to manipulate device DMA operations or cause denial of service through resource exhaustion caused by corrupted translation caches, although direct exploitation is complex and dependent on specific hardware configurations and timing conditions.
The resolution involves modifying the split page table allocation logic in x86/mm/pat.c to use the ordinary PTE allocation API at split time rather than allocating memory directly. This ensures that the standard page table constructor is invoked, properly initializing the folio and marking it as a kernel page table. The fix also introduces conditional calls to pagetable_dtor_free() if the PG_table flag is set on the ptdesc, otherwise falling back to pagetable_free(), ensuring that all pages marked as kernel page tables follow the correct path through pagetable_free_kernel(). This guarantees that deferred freeing and IOTLB invalidation logic are correctly applied. Administrators should apply this patch immediately to prevent potential stability issues or security implications arising from stale IOTLB entries, particularly on systems with active DMA operations or complex memory mapping scenarios involving large page splits.