From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: linux-cve-announce@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@kernel.org>
Subject: CVE-2026-80893: mm/hugetlb: fix swap entry corruption when clearing uffd-wp at fork()
Date: Fri, 4 Sep 2026 19:09:34 +0200 [thread overview]
Message-ID: <2026090430-CVE-2026-80893-abce@gregkh> (raw)
From: Greg Kroah-Hartman <gregkh@kernel.org>
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.
The Linux kernel CVE team has assigned CVE-2026-80893 to this issue.
Affected and fixed versions
===========================
Issue introduced in 5.19 with commit bc70fbf269fdff410b0b6d75c3770b9f59117b90 and fixed in 6.1.183 with commit f1b1311c0352873137768bac5a126e491271a747
Issue introduced in 5.19 with commit bc70fbf269fdff410b0b6d75c3770b9f59117b90 and fixed in 6.6.151 with commit 69cb5825d9988c7944bc9f1dc08cb233655405a7
Issue introduced in 5.19 with commit bc70fbf269fdff410b0b6d75c3770b9f59117b90 and fixed in 6.12.103 with commit 8b0de7005b148738d79d6c45594d566489948a68
Issue introduced in 5.19 with commit bc70fbf269fdff410b0b6d75c3770b9f59117b90 and fixed in 6.18.44 with commit 2b9a07002c2f296aa6a9c591213933d3492e3089
Issue introduced in 5.19 with commit bc70fbf269fdff410b0b6d75c3770b9f59117b90 and fixed in 7.1.8 with commit 2fa11c60c9c06bafc19cf4d9efdaa36a38079e87
Issue introduced in 5.19 with commit bc70fbf269fdff410b0b6d75c3770b9f59117b90 and fixed in 7.2 with commit 83abe2fd5b3aeb3123b5408a5a91709c5538fb23
Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.
Unaffected versions might change over time as fixes are backported to
older supported kernel versions. The official CVE entry at
https://cve.org/CVERecord/?id=CVE-2026-80893
will be updated if fixes are backported, please check that for the most
up to date information about this issue.
Affected files
==============
The file(s) affected by this issue are:
mm/hugetlb.c
Mitigation
==========
The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes. Individual
changes are never tested alone, but rather are part of a larger kernel
release. Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all. If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
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
reply other threads:[~2026-09-04 17:14 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2026090430-CVE-2026-80893-abce@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=cve@kernel.org \
--cc=gregkh@kernel.org \
--cc=linux-cve-announce@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.