Description

In the Linux kernel, the following vulnerability has been resolved: mm/util: don't read __page_2 for order-1 folios in snapshot_page() snapshot_page() currently reads __page_2 after checking nr_pages > 1, but it should only do so when nr_pages > 2. If an order-1 folio is allocated at the end of a vmemmap section, __page_2 will not exist and reading it will cause a fault. During DLPAR memory remove on a 22 TB ppc64le LPAR, snapshot_page() oopsed on the page isolation path while reading an order-1 folio's __page_2 from an adjacent absent section (unmapped vmemmap). Fix this to avoid reading memmap that doesn't exist (e.g., a vmemmap hole).

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.1",
  "pubDate": "2026-08-28T08:16:53.963Z",
  "pubdate": "2026-08-28T08:16:53.963Z",
  "executiveSummary": "The Linux kernel suffers from an out-of-bounds memory access vulnerability in the snapshot_page() function, specifically concerning the handling of order-1 folios.\nThe vulnerability stems from an incorrect conditional check that attempts to access __page_2 for folios with a size greater than 1 page, rather than greater than 2 pages.\nThis behavior leads to a kernel panic (oops) when an order-1 folio is located at the boundary of a vmemmap section, as the pointer targets an unmapped or absent memory region.\nThe primary impact is a Denial of Service (DoS) resulting from a system crash during memory operations, such as Dynamic Logical Partitioning (DLPAR) memory removal.\nThe flaw affects high-memory systems, notably observed on large-scale ppc64le LPAR architectures, where page isolation processes trigger the fault.\nExploitation requires no specific network access or authentication; it is a memory management logic error triggered by standard system operations involving page isolation or memory hot-plugging.\nRisk is categorized as high for stability in mission-critical environments utilizing memory-intensive workloads.",
  "technicalDetails": "The root cause of this vulnerability lies in the improper implementation of bounds checking within the mm/util.c file, specifically in the snapshot_page() function. The function is responsible for gathering information about folio pages during memory management operations.\nIn the affected code, snapshot_page() evaluates the number of pages (nr_pages) within a folio. Currently, the code executes a read operation on the __page_2 member of the page structure whenever nr_pages > 1. However, __page_2 is only valid if the folio spans more than two pages (order > 1).\nWhen an order-1 folio (consisting of exactly two pages) is allocated at the extreme end of a vmemmap section, the memory address corresponding to __page_2 resides outside the valid range of the current memory section. If the adjacent section is absent or unmapped, accessing this pointer results in a page fault or a general protection fault within the kernel space.\nThe attack flow is triggered during memory isolation routines, such as those executed during DLPAR memory removal on large-scale systems. As the kernel traverses the page metadata to isolate memory, it blindly accesses the __page_2 structure. Because the kernel assumes the memory mapping for the folio is continuous, it does not account for gaps between sections in the vmemmap.\nThe technical failure sequence is as follows: 1) A folio of order-1 is allocated at the edge of a memory section. 2) The snapshot_page() function is called as part of a memory management task. 3) The function logic triggers an access to the structure pointer __page_2. 4) The hardware/MMU attempts to resolve the address of __page_2, which points to an unmapped vmemmap hole. 5) A kernel oops is triggered due to an invalid memory access, causing the system to panic and enter an unstable state.\nThis vulnerability is localized to the kernel's memory management subsystem. While it does not allow for direct code execution, the resulting system crash on large memory configurations represents a significant availability vulnerability. The issue persists across versions of the Linux kernel where the logic in snapshot_page() is misaligned with the folio order requirements for accessing __page_2."
}