All of lore.kernel.org
 help / color / mirror / Atom feed
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.