CVE-2026-80893 in Linux
Summary
by MITRE • 09/04/2026
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.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/04/2026
The Linux kernel contains a critical memory management vulnerability within the huge page handling subsystem that results in swap entry corruption during process forking operations. This flaw specifically affects the copy_hugetlb_page_range function, which is responsible for duplicating virtual memory area mappings when a new child process is created via fork(). The core technical issue stems from an incorrect bit manipulation strategy used to clear the userfaultfd write-protect (uffd-wp) flag on non-present page table entries. When encountering migration or hardware poison swap entries, the kernel incorrectly applies huge_pte_clear_uffd_wp(), a function designed for present physical memory mappings that operates on the position of the present-PTE bit. This is fundamentally flawed because swap entries store their metadata and state information in different bit positions than resident pages. Specifically, while migration entries correctly utilize dedicated functions like pte_swp_uffd_wp() to manage the uffd-wp flag, the incorrect application of the present-bit clearing logic inadvertently modifies bits within the swap payload itself rather than a non-existent status flag.
On x86-64 architectures, this bit manipulation error has severe consequences for data integrity because it targets the inverted swap offset field within the encoded swap entry structure. In this architecture, naturally aligned huge page physical frame numbers consistently have specific bits set in their representation. By clearing what was intended to be a status flag but is actually part of the numerical offset value, the kernel inadvertently alters the underlying address calculation. This results in an arithmetic error where the encoded physical frame number advances by two pages for every affected entry copied into the child process. The vulnerability does not require any active userfaultfd registration or complex fault handling scenarios to trigger; it occurs simply when a parent process with an in-flight hugetlb migration entry or a poisoned page forks, leading immediate and silent corruption of the memory mapping metadata in the newly created child process.
The operational impact of this vulnerability is characterized by latent data corruption that may not manifest immediately but can lead to significant system instability under specific conditions. Initially, many instances of this corruption heal themselves automatically because reverse map walks identify migration entries based on folio ranges and functions like remove_migration_pte() reconstruct the page table entry from the correct folio information once migration completes. However, if the corrupted swap offset is re-encoded through other kernel paths such as hugetlb_change_protection(), which may rewrite a writable migration entry using make_readable_migration_entry with the flawed swp_offset value, the corruption propagates and persists. This can lead to incorrect memory access patterns, potential data loss, or system crashes when the process attempts to utilize these corrupted mappings later in its execution lifecycle.
To mitigate this vulnerability, developers have implemented targeted fixes that distinguish between different types of non-present entries based on their semantic meaning regarding write protection flags. For migration entries, which legitimately carry the uffd-wp bit and require it to be cleared during forking if not registered with userfaultfd, the fix replaces the incorrect present-bit clearing function with pte_swp_clear_uffd_wp(). This ensures that only the appropriate metadata bits are modified without affecting the swap offset payload. Conversely, for hardware poison entries, which never carry the uffd-wp bit as they are installed fresh by make_hwpoison_entry and do not preserve this flag through unmapping operations, the unnecessary clearing operation is entirely removed. These changes align with established industry standards regarding memory safety and correct handling of virtual memory descriptors. The vulnerability relates to CWE-120 Buffer Copy without Checking Size of Input in terms of incorrect bit manipulation leading to data corruption, and it can be contextualized within MITRE ATT&CK techniques involving privilege escalation or denial of service through resource exhaustion if the corrupted mappings lead to kernel panics or unstable system behavior during high-fork-rate workloads.