CVE-2026-80685

The Linux kernel's memory-management helper snapshot_page() reads the __page_2 field of any folio spanning more than one page (nr_pages > 1), although that field only exists when nr_pages > 2, so order-1 folios can be read past the end of their mapped vmemmap. If an order-1 folio sits at the end of a vmemmap section, __page_2 lies in the next, absent (unmapped) section and the access faults — observed as a kernel oops on the page-isolation path during DLPAR (dynamic logical partitioning) memory removal on a 22 TB ppc64le LPAR. A local actor (per CVSS: local vector, low privileges) or an administrator performing memory reconfiguration gains a kernel crash and loss of availability of the host or partition; the 7.1 CVSS score also credits high confidentiality impact, though no information-disclosure exploit is known. Those affected are Linux kernel deployments that exercise the memory hot-remove/isolation path with vmemmap — in practice chiefly IBM POWER (ppc64le) systems using DLPAR, with other vmemmap-backed architectures plausibly exposed; the disclosure provides no affected or fixed version numbers. No public proof-of-concept exists, the issue is not in CISA KEV, and EPSS estimates a 0.1% 30-day exploitation probability, so no in-the-wild exploitation is known.

What to do: Track your distribution's advisory for CVE-2026-80685 and apply the backported mm/util snapshot_page() fix as soon as it is available, prioritizing ppc64le systems that use DLPAR or other memory hot-remove operations. Until patched, defer dynamic memory-removal operations on large POWER partitions (and any hot-remove workloads) to maintenance windows. Since no fixed version numbers appear in the disclosure, verify with your vendor that the shipped kernel includes the snapshot_page() correction.