CVE-2026-80893 mm/hugetlb: fix swap entry corruption when clearing uffd-wp at fork()
A local attacker can corrupt hugetlb swap entries during fork, potentially leading to privilege escalation or denial of service in the Linux kernel.
- Exploited in the wild
- Not known
- Login needed
- Not needed
- Attackable
- Local or same network only
- Victim action needed
- Not needed
- Fix
- Available
What is CVE-2026-80893?
CVE-2026-80893 is a memory corruption vulnerability in Linux, published on 4 Sep 2026. It can only be exploited from the same machine or local network, with no action from the victim.
Official description
In the Linux kernel, the following vulnerability has been resolved:
mm/hugetlb: fix swap entry corruption when clearing uffd-wp at fork()
copy_hugetlb_page_range() clears the uffd-wp bit of migration and hwpoison entries with huge_pte_clear_uffd_wp(), which operates on the present-PTE bit position. Swap entries keep the uffd-wp state elsewhere -- the migration branch reads and sets it with pte_swp_uffd_wp() and pte_swp_mkuffd_wp() -- and the present-PTE position falls into the swap payload. On x86-64 it lands in the inverted swap offset, where a naturally-aligned hugetlb PFN always has the affected bit set, so the clear advances the encoded PFN by two pages.
No userfaultfd needs to be involved: the clear is guarded only by the child VMA not being uffd-wp registered, so a plain fork() with an in-flight hugetlb migration entry (or a poisoned hugetlb page) corrupts the entry copied into the child. Instrumenting the clear and forking after MADV_HWPOISON on a 2MB anon hugetlb page shows:
offset before=120e00 offset after =120e02
The fallout is mostly latent: rmap walks match migration entries by folio range and remove_migration_pte() rebuilds the PTE from the folio, so a within-folio PFN skew heals once migration completes. But any path that re-encodes the corrupted offset -- e.g. hugetlb_change_protection() rewriting a writable migration entry via make_readable_migration_entry(swp_offset(entry)) -- propagates it.
Migration entries legitimately carry uffd-wp, so clear it with pte_swp_clear_uffd_wp(), matching copy_nonpresent_pte() and move_huge_pte().
A hwpoison entry, on the other hand, never carries the uffd-wp bit: it is installed fresh by make_hwpoison_entry() (try_to_unmap_one() does not preserve uffd-wp on the hwpoison path) and hugetlb_change_protection() leaves hwpoison entries untouched. There was nothing to clear there, only the corruption, so drop the clear entirely.
Which versions are affected by CVE-2026-80893?
How do I fix CVE-2026-80893?
Apply the vendor's patch.
Upgrade to the fixed version. Memory-safe languages, compiler hardening and fuzzing prevent most new cases. More about Memory corruption.
Is CVE-2026-80893 being exploited?
There is no known exploitation of CVE-2026-80893 in the wild and no public exploit code.
Sources
Also known as AZL-99609, BELL-CVE-2026-80893, DEBIAN-CVE-2026-80893, GHSA-84rp-g9wq-249m, UBUNTU-CVE-2026-80893.