CVE-2026-80893mm/hugetlb: fix swap entry corruption when clearing uffd-wp at fork()
Updated under an hour ago ()
Does this affect you?
It affects Linux. Add what you run to find out whether that includes you.
No exploitation reported and no EPSS estimate yet.
Do this next
Free account, 1 product
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.
- CVSS
- Not yet scored
- Weakness (CWE)
- Not given
- Known exploited
- Not in CISA's KEV catalog
- EPSS (exploitation in the next 30 days)
- Not loaded for this CVE
- Assigned by
- Linux
- NVD analysis
- Received
- Record last updated
- Sep 4, 2026
- First seen by InfoSec Signals
- Oct 9, 2026
Affected products
Linux Linux linux:linux (from the name) | from bc70fbf269fdff410b0b6d75c3770b9f59117b90 before f1b1311c0352873137768bac5a126e491271a747; from bc70fbf269fdff410b0b6d75c3770b9f59117b90 before 69cb5825d9988c7944bc9f1dc08cb233655405a7; from bc70fbf269fdff410b0b6d75c3770b9f59117b90 before 8b0de7005b148738d79d6c45594d566489948a68; from bc70fbf269fdff410b0b6d75c3770b9f59117b90 before 2b9a07002c2f296aa6a9c591213933d3492e3089; from bc70fbf269fdff410b0b6d75c3770b9f59117b90 before 2fa11c60c9c06bafc19cf4d9efdaa36a38079e87; from bc70fbf269fdff410b0b6d75c3770b9f59117b90 before 83abe2fd5b3aeb3123b5408a5a91709c5538fb23 | CNA record |
References
- https://git.kernel.org/stable/c/f1b1311c0352873137768bac5a126e491271a747
- https://git.kernel.org/stable/c/69cb5825d9988c7944bc9f1dc08cb233655405a7
- https://git.kernel.org/stable/c/8b0de7005b148738d79d6c45594d566489948a68
- https://git.kernel.org/stable/c/2b9a07002c2f296aa6a9c591213933d3492e3089
- https://git.kernel.org/stable/c/2fa11c60c9c06bafc19cf4d9efdaa36a38079e87
- https://git.kernel.org/stable/c/83abe2fd5b3aeb3123b5408a5a91709c5538fb23
The CVE record on cve.org NVD's entry
The CVE record is authoritative. Products marked “from the name” were identified from the CNA's free-text names, not a CPE, and are matched less certainly. This product uses the NVD API but is not endorsed or certified by the NVD.