data built 2026-10-19T13:16:53Z

Look up another CVE · open CVE-2026-72175 in the interactive tracker

CVE-2026-72175

fs/proc/task_mmu: fix make_uffd_wp_huge_pte() prot-update race

7.1 EPSS 0.2% AV:L

Published 2026-08-15 (2 months ago) by the Linux kernel CNA. Subsystem fs/proc. Debian urgency: unimportant.

What to do, per Debian release

Debian's own status for CVE-2026-72175 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source

ReleaseStatus VersionWhat this means
Debian 12bookwormnot affected6.1.190-1Nothing to do. bookworm never shipped the vulnerable code.
Debian 13trixiefixed6.12.101-1Update the kernel and reboot. Fixed in 6.12.101-1. A running kernel keeps the old code until the machine restarts.
Debian 14forkyfixed7.1.5-1Update the kernel and reboot. Fixed in 7.1.5-1. A running kernel keeps the old code until the machine restarts.
Debian unstablesidfixed7.1.5-1Update the kernel and reboot. Fixed in 7.1.5-1. A running kernel keeps the old code until the machine restarts.
Debian 12bookworm · linux-6.12fixedDLA-4745-1 · 2026-08-18 · text6.12.101-1~deb12u1Update the kernel and reboot. DLA-4745-1 shipped the fix on 2026-08-18, in 6.12.101-1~deb12u1. A running kernel keeps the old code until the machine restarts.

The vulnerability

What the bug is

Patch series "userfaultfd/pagemap: pre-existing fixes". These are pre-existing bug fixes that were carried at the front of the userfaultfd RWP working-set-tracking series up to v5 [1]. Per review feedback that fixes should not sit in the middle of a feature series, they are split out and sent on their own; the RWP series is reposted rebased on top of this. All six were flagged by the Sashiko AI review of the RWP series and carry independent of RWP, apply to mm-new directly, and carry Cc: stable@. 1: fs/proc/task_mmu: a missing huge_ptep_modify_prot_start() in make_uffd_wp_huge_pte() can lose hardware Dirty/Accessed updates when PAGEMAP_SCAN write-protects a hugetlb PTE. 2: fs/proc/task_mmu: pagemap_scan_hugetlb_entry() compares the range against HPAGE_SIZE rather than the hstate page size, so it never write-protects gigantic hugetlb pages. 3: fs/proc/task_mmu: PAGEMAP_SCAN with PM_SCAN_WP_MATCHING over an unpopulated hugetlb range self-deadlocks -- pagemap_scan_pte_hole() calls uffd_wp_range() while walk_hugetlb_range() holds the hugetlb vma lock for read, and hugetlb_change_protection() then takes it for write. Install the marker inline instead. 4: mm/huge_memory: change_non_present_huge_pmd() drops pmd_swp_uffd_wp on a device-private PMD permission downgrade, silently losing the uffd-wp marker. 5: userfaultfd: must_wait() applies pte_write() to a locklessly read PTE without checking pte_present(), so swap/migration entries decode random offset bits and a thread can stay parked on a stale fault. 6: userfaultfd: __VMA_UFFD_FLAGS feeds VMA_UFFD_MINOR_BIT (41) to mk_vma_flags() unconditionally, an out-of-bounds write into the single-word vma_flags_t on 32-bit. Build the mask from config-gated per-mode masks so an unavailable bit is never materialised. This patch (of 6): make_uffd_wp_huge_pte() arms the UFFD_WP bit on a present HugeTLB PTE by calling huge_ptep_modify_prot_commit() with a ptent snapshot that was fetched without the corresponding huge_ptep_modify_prot_start(). The start helper is what atomically clears the entry so the kernel-owned snapshot stays consistent until the commit; without it, the hardware may set Dirty or Accessed in the live PTE between the original read and the commit, and huge_ptep_modify_prot_commit() (whose generic implementation just calls set_huge_pte_at()) then writes the stale snapshot back over the live hardware bits, losing the update. The non-hugetlb sibling make_uffd_wp_pte() does this correctly via ptep_modify_prot_start() / ptep_modify_prot_commit(). Mirror that pattern for the present-PTE branch. The migration case stays as-is -- migration entries are non-present, so there's no hardware update to race against.

Where it lives

The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.

fs/proc/task_mmu.c

What this is
MEMORY MAPPINGMAINTAINERS section matched on fs/proc/task_mmu.c · linux-mm@kvack.org · Maintained

Check it on the machine

grep -wE 'CONFIG_MMU|CONFIG_PROC_FS' /boot/config-$(uname -r)

Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.

Show whether Debian builds this, per release

Debian builds this code. Every release below compiles the affected file into the kernels it ships.

  • bookworm, trixie, forky, sid, bookworm · linux-6.12y
y
built into the kernel image on every flavour - only a patch removes it
Build switches
CONFIG_MMU, CONFIG_PROC_FS
Reads as
all on means the file is compiled; any one off means it is not.

From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages

Signals

Published
2026-08-15 (2 months ago)source
CVSS
7.1 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Nsource recompute it
Attack vector
local (AV:L)source
EPSS
0.17%, higher than 6.1% of all CVEssource
CISA KEV
not listedthe KEV catalogue
Debian urgency
unimportantsource
Subsystem
fs/proc

Upstream fixes

The versions the CNA records as introducing and fixing this, and the commit for each. source

IntroducedFixed inCommit
6.76.12.10150a25249a635
6.76.18.428e39ed92d7c5
6.77.1.56b7f774b8882
6.77.204718f7c9290

Debian advisories

AdvisoryDateShipped toDebian
DLA-4745-12026-08-18bookworm 6.12.101-1~deb12u1tracker

Why the CNA scored it this way

Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source

AV:LAttack vector, local
The bug is reached only through the PAGEMAP_SCAN ioctl on /proc/<pid>/pagemap, which requires local access to a process address space and cannot be triggered remotely.
AC:LAttack complexity, low
The attacker controls both sides of the race by issuing PAGEMAP_SCAN with PM_SCAN_WP_MATCHING while concurrently writing the same present HugeTLB page from another thread in the target process.
PR:LPrivileges required, low
Any unprivileged local user can open /proc/self/pagemap and trigger the ioctl; ptrace read checks also allow same-UID access to another process's pagemap without real root privileges.
UI:NUser interaction, none
No victim user action is required; exploitation is performed entirely by the attacker ioctl-ing pagemap and racing writes against their own or same-UID process mappings.
S:UScope, unchanged
The vulnerability corrupts PTE metadata within the target mm only and does not cross VM, container, or kernel/user security boundaries.
C:HConfidentiality impact, high
Stale HugeTLB PTE commits can clear hardware Dirty/Accessed bits; this PTE corruption can expose stale file-backed data to other mappers or userfaultfd migration consumers instead of current memory contents.
I:HIntegrity impact, high
Lost Dirty bits break folio dirty tracking and writeback for HugeTLB mappings, allowing silent loss or corruption of in-memory modifications that should have been persisted or migrated.
A:NAvailability impact, none
The race corrupts PTE metadata without causing kernel oops, panic, or hang; availability impact is limited to incorrect page state rather than system crash.