CVE-2026-80685: mm/util: don't read __page_2 for order-1 folios in snapshot_page()
In the Linux kernel, the following vulnerability has been resolved:
mm/util: don't read page2 for order-1 folios in snapshotpage()
snapshotpage() currently reads page2 after checking nrpages > 1, but it should only do so when nrpages > 2.
If an order-1 folio is allocated at the end of a vmemmap section, page2 will not exist and reading it will cause a fault.
During DLPAR memory remove on a 22 TB ppc64le LPAR, snapshotpage() oopsed on the page isolation path while reading an order-1 folio's page2 from an adjacent absent section (unmapped vmemmap).
Fix this to avoid reading memmap that doesn't exist (e.g., a vmemmap hole).
Affected Software
Event History
Frequently Asked Questions
Which systems are most likely to encounter this fault?
Systems performing memory hot-remove or DLPAR memory removal are the demonstrated exposure case. The fault requires an order-1 folio at the end of a vmemmap section where the adjacent section is absent or has an unmapped vmemmap hole.
What is the operational impact if the issue is triggered?
The kernel can fault and oops in snapshot_page() during the page-isolation path, because it reads __page_2 even though that memmap entry does not exist.
Is ordinary memory allocation alone sufficient to trigger the issue?
The provided information identifies a specific boundary condition: an order-1 folio must be allocated at the end of a vmemmap section, followed by access to snapshot_page(). The reported trigger occurred during DLPAR memory removal.