Cloudanix VulnDB

CVE-2026-80893

None

CVSS

—

EPSS

0.2%

Published

Sep 4, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A Linux kernel bug can silently damage internal tracking information for certain large memory pages when programs duplicate themselves, potentially causing later crashes or incorrect behavior in affected applications.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Data Tampering
Component
OS kernel
Class
Memory Corruption
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

The vulnerability corrupts hugetlb migration or hwpoison swap entries during fork by using huge_pte_clear_uffd_wp on the present-PTE bit position that overlaps the swap payload, advancing the encoded PFN by two pages on x86-64 and allowing subsequent re-encoding paths such as hugetlb_change_protection to propagate the invalid offset.

Why it matters to the business

Systems relying on hugetlb pages may experience latent memory management errors after fork operations, increasing risk of application instability or data integrity issues until the kernel is updated.

How an attack unfolds

An attacker creates a hugetlb mapping, induces a migration entry or hwpoison page via MADV_HWPOISON or similar, then performs a fork from a VMA without uffd-wp registration; the corrupted child entry can later be re-encoded by protection-change or similar paths to produce observable side effects.

How to fix it

Update to a Linux kernel containing the fix that replaces huge_pte_clear_uffd_wp with pte_swp_clear_uffd_wp for migration entries and removes the erroneous clear for hwpoison entries; rebuild and reboot affected systems.

How to confirm the fix worked

Confirm the running kernel contains the commit that changes copy_hugetlb_page_range to call pte_swp_clear_uffd_wp and drops the hwpoison clear path; re-run the reported offset-before/offset-after instrumentation test to verify no PFN skew occurs on fork after MADV_HWPOISON.

Typical attack path

  1. Map a hugetlb region and trigger a migration or hwpoison state on a page
  2. Perform fork while the migration/hwpoison entry exists and the child VMA lacks uffd-wp registration
  3. Execute operations that re-encode the corrupted swap offset (for example hugetlb_change_protection on a writable migration entry)
  4. Observe or exploit resulting folio-range or PTE inconsistencies in the child process

How to detect it

Search kernel logs and audit trails for hugetlb-related warnings or oopses that mention migration entries or swap offsets after fork; examine user-space code paths that combine hugetlb mappings, MADV_HWPOISON, and subsequent mprotect or protection changes.

What your security team should do

  • Prioritize kernel updates on systems that use hugetlb pages (databases, HPC, virtualization hosts)
  • Monitor upstream stable branches and distribution security feeds for the backported fix
  • Limit hugetlb usage to workloads that can tolerate brief exposure until patched
  • Test fork-heavy workloads with migration and hwpoison scenarios after applying the update

The record

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.

Affected packages

Ecosystem Package Introduced Fixed