Skip to content
Fencer Vulns
no cvss —

CVE-2026-74672 json

mm/vmalloc: acquire init_mm lock on huge vmap to avoid ptdump UAF

published 2026-08-22 2 mo ago modified 2026-11-06 2 d ago also EUVD-2026-64359

cvss
—
not scored
cisa kev
Not listed
not in CISA's catalog
epss
0.2%
EPSS 0.2% chance of exploitation in 30 days, percentile 7%
public exploits
0
none known

Summary

In the Linux kernel, the following vulnerability has been resolved:

mm/vmalloc: acquire init_mm lock on huge vmap to avoid ptdump UAF

Patch series "mm: fix UAF caused by race between ptdump and vmap pgtable freeing", v6.

Kernel page table walkers fall into two broad categories - those ranges where no exclusion is required via walk_kernel_page_table_range_lockless() and those where exclusion is required via walk_kernel_page_table_range() or walk_page_range_debug().

The former category is used only by arm64 arch code operating on ranges it both wholly owns and does not concurrently write.

The latter category consists of kernel page table walkers operating on ranges that are wholly owned (but which need exclusion against concurrent writers).

The lock used for exclusion is the mmap lock, and for kernel ranges this is the mmap lock on init_mm.

ptdump is a special case being both the only user of walk_page_range_debug(), and the only case in which it walks ranges it does not own.

This presents a problem, as page tables may be freed under ptdump. And indeed there is a use-after-free bug in the kernel as a result, which this series addresses.

vmap promotes page tables to huge leaf entries where possible, freeing the lower page table when it does. It does this with no meaningful locks held against concurrent ptdump walks.

As a result, use-after-free can currently occur. This series addresses the issue by having the vmap huge promotion logic acquire the mmap read lock while both setting the huge page table entry and freeing the prior leaf page table.

The ptdump code already acquires the mmap write lock, so by doing so we ensure that the ptdump walker only ever observes either the huge page table entry or the existing page table entry, and nothing is freed underneath it.

A mitigation for this issue was already applied for arm64 in commit fa93b45fd397 ("arm64: Enable vmalloc-huge with ptdump"), which this series has to deal with carefully.

This mitigation resolves the issue by acquiring the mmap read lock on init_mm on vmap page table free if a ptdump is in progress.

However the fix in this series would cause a deadlock if we were to simply apply it for arm64 without also reverting the change.

This is because vmap may acquire the read lock before ptdump attempts to acquire the write lock, which then gets queued, and rwsem starvation rules mean that the (unacknowledged) nested mmap read lock in the arm64 code would also block, meaning the original read lock is never released and thus deadlock.

This series works around this by #ifndef CONFIG_ARM64'ing the mmap read lock in vmap logic, then partially reverting commit fa93b45fd397 ("arm64: Enable vmalloc-huge with ptdump"), keeping the enablement of huge vmap support, and removing the ifdeffery with the partial revert patch.

There are related issues that are also addressed in this series:

* x86 page attribute logic, specifically Change Page Attributes (CPA), implements a feature whereby huge ranges can be collapsed into huge leaf entries. This can similarly cause a UAF when done in parallel with a ptdump walk, so similarly acquire the init_mm mmap lock to avoid this.

* The CPA logic allows concurrent page table manipulation and CPA collapse, meaning the former risks accessing a page table the latter frees. Fix this by acquiring mmap write lock on init_mm across the whole CPA collapse operation and read lock on the page table manipulation.

* x86 and arm64 permit walks of non-kernel mm's (both allowing efi mm walks, and in x86's case arbitrary mm's), so we ensure kernel mappings remain stable by locking the init_mm as well as the mm being walked.

The ordering of patches is established for both strict dependencies (the arm64 partial revert in particular has to be done after the vmap changes) and logical ones (the non-kernel mm fix only makes sense once the vmap/CPA fixes are in place).

This patch (of 3):

Currently there is a nasty ra ---truncated---

Patch / fix

  • Linux Linux 4.5, 4.10, 4.15, 4.16, 5.10.273, 5.15.224, 6.1.184, 6.6.153, 6.12.105, 6.18.45, 7.1.9, 7.2
  • linux Debian 12 6.1.187-1
  • linux Debian 13 6.12.105-1
  • linux Debian 14 7.1.9-1
  • linux-6.12 Debian 12 6.12.107-1~deb12u1

debian advisories DEBIAN-CVE-2026-74672

  • linux Ubuntu 26.04 LTS 7.0.0-42.42
  • linux-aws Ubuntu 26.04 LTS 7.0.0-1016.17
  • linux-gcp Ubuntu 26.04 LTS 7.0.0-1016.18
  • linux-ibm Ubuntu 26.04 LTS 7.0.0-1017.17
  • linux-riscv Ubuntu 26.04 LTS 7.0.0-42.42.1
  • linux-oracle Ubuntu 26.04 LTS 7.0.0-1015.16
  • linux-hwe-7.0 Ubuntu 24.04 LTS 7.0.0-42.42~24.04.1
  • linux-oem-7.0 Ubuntu 26.04 LTS 7.0.0-1017.17

ubuntu advisories UBUNTU-CVE-2026-74672

Ubuntu security data © Canonical Ltd., from https://github.com/canonical/ubuntu-security-notices via OSV; changed: normalised to fixed package versions per release. CC BY-SA 4.0

  • kernel Azure Linux 3.0 6.6.157.1-1

azure linux advisories AZL-97292

Azure Linux vulnerability data, Copyright (c) Microsoft Corporation, from https://github.com/microsoft/AzureLinuxVulnerabilityData via OSV, under the MIT licence; changed: normalised to fixed package versions per release. MIT

Vendor advisories

What the vendors themselves say about their products: affected, fixed or not affected, and what to do.

red hat product security vex CVE-2026-74672 updated cvss 4.7

kernel: mm/vmalloc: acquire init_mm lock on huge vmap to avoid ptdump UAF

  • Red Hat Enterprise Linux 6 perf, kernel, python-perf, kernel-kdump, kernel-firmware, kernel-bootwrapper, +1 more
    affected: workaround, no fix planned “Out of support scope”
  • Red Hat Enterprise Linux 8 perf, kernel, bpftool, kernel-rt, kernel-core, kernel-tools, +29 more Red Hat Enterprise Linux 9 rv, perf, rtla, kernel, bpftool, libperf, +83 more Red Hat Enterprise Linux 10 kernel
    affected: workaround, no fix available “Fix deferred”
  • Red Hat Enterprise Linux 7 perf, kernel, bpftool, kernel-rt, python-perf, kernel-kdump, +8 more
    not affected: vulnerable code not present

Red Hat CSAF VEX © Red Hat, Inc., from https://security.access.redhat.com/data/csaf/v2/vex/; changed: reduced to product statuses and remediations. CC BY 4.0 · csaf

CISA SSVC

Exploitation
none
Automatable
no
Technical impact
partial
Assessed
2 d ago

Exploit prediction

0.18% chance of exploitation in the next 30 days, higher than 7% of all scored CVEs (FIRST EPSS, 2026-11-08).

Affected products

  • Linux Linux

Classification

Technology feeds

References

Sources

Fencer Vulns keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.