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.
Published: 2026-09-04
Score: n/a
EPSS: < 1% Very Low
KEV: No
Impact: Potential local privilege escalation through kernel memory corruption
Action: Immediate Patch
AI Analysis

Impact

The vulnerability arises from a bug in the Linux kernel’s hugetlb management where clearing the uffd-wp bit incorrectly advances a swap offset. This corruption can overwrite adjacent data structures, potentially allowing an attacker who can trigger a fork with an in-flight huge-page migration or poisoned page to manipulate kernel memory. The resulting memory corruption could lead to arbitrary code execution or privilege escalation within the local system. The weakness is a classic out‑of‑bounds write, where a pointer is moved incorrectly into swap payload fields. No userfaultfd is required; the flaw is triggered simply by a plain fork under the described conditions.

Affected Systems

All Linux kernel versions that include the affected hugetlb code path, i.e. all officially supported releases prior to the commit that fixed the bug. The specific affected versions are not enumerated in the CVE data, so any kernel in use that has not incorporated the patch is at risk. Kernel builds that do not enable hugetlb features are not affected.

Risk and Exploitability

The CVE report does not list a CVSS score; thus the exact severity is not quantified. EPSS is not available, and the vulnerability is not in the CISA KEV catalog. Because the exploit requires a local process and the corruption path depends on internal kernel state, the likelihood of exploitation in the wild is modest but non‑negligible. An attacker who can execute code or perform privileged actions on the host can cause a fork operation with a migrating or poisoned huge page to corrupt kernel data, potentially enabling privilege escalation.

Generated by OpenCVE AI on September 4, 2026 at 19:44 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Apply a Linux kernel release that incorporates the commit fixing hugetlb swap entry corruption.
  • Reboot the node to ensure all memory structures are re‑initialized after the kernel upgrade.
  • If kernel upgrades are not immediately possible, disable hugetlb features or prevent fork operations while huge pages are in migration or poisoned state, and monitor for swap entry corruption via system logs.

Generated by OpenCVE AI on September 4, 2026 at 19:44 UTC.

Tracking

Sign in to view the affected projects.

Advisories
Source ID Title
Debian DLA Debian DLA DLA-4777-1 linux security update
Debian DLA Debian DLA DLA-4788-1 linux-6.12 security update
History

Fri, 04 Sep 2026 20:00:00 +0000

Type Values Removed Values Added
Weaknesses CWE-119

Fri, 04 Sep 2026 17:30:00 +0000

Type Values Removed Values Added
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.
Title mm/hugetlb: fix swap entry corruption when clearing uffd-wp at fork()
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-09-04T17:11:09.199Z

Reserved: 2026-08-26T14:34:25.800Z

Link: CVE-2026-80893

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-09-04T18:17:57.467

Modified: 2026-09-04T18:17:57.467

Link: CVE-2026-80893

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-09-04T23:15:04Z

Weaknesses
  • CWE-119

    Improper Restriction of Operations within the Bounds of a Memory Buffer