[CVE-2026-74672][MODERATE 7.0] mm/vmalloc: acquire init_mm lock on huge vmap to avoid ptdump UAF

[AL-KERNEL <alkernel@kernelcve.org>]

CVE: CVE-2026-74672
Priority: MODERATE 7.0
AL-KERNEL base severity: MODERATE
KPANIC flag: YES
Patch: mm/vmalloc: acquire init_mm lock on huge vmap to avoid ptdump UAF
Commit: c5bf8cd148cfea948cfa3db71da427294b20db0f
Upstream patch: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=c5bf8cd148cfea948cfa3db71da427294b20db0f
Original CVE announcement: https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-74672
Analysis date: Sat, 22 Aug 2026 15:39:51 -0400
ActionableScore: 7
ActionableScore lower bound: 3
Actionable bucket: Strong Important candidate / Actionable Moderate at minimum
Manual review required: YES

Summary:
A race between ptdump page-table walking and huge vmap page-table promotion can let ptdump access a freed lower-level page table, causing a kernel use-after-free and possible memory corruption, with practical reachability usually limited to local privileged or delegated debug access.

======================================================================
ABOUT THIS REPORT
======================================================================

The original Linux kernel CVE announcement for CVE-2026-74672 is available here:
https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-74672

The original announcement does not normally provide a security severity
estimate, CVSS assessment, or enough information to determine whether the
reported kernel bug represents a practically relevant security issue.

This report was generated by AL-KERNEL, an AI-assisted Linux kernel
vulnerability analysis system developed by Alexander Larkin. It combines
an autonomous classifier with LLM-assisted technical analysis and a
separate ActionableScore mechanism.

The purpose of this report is to prioritize Linux kernel CVEs before
manual review, identify cases that require prompt investigation, and
support automatic closure of issues that are unlikely to have meaningful
security impact.

Published priority for this report: MODERATE 7.0
Manual review required: YES

A detailed explanation of the methodology and priority rules is included
at the end of this message.

======================================================================
AL-KERNEL CLASSIFICATION RESULT
======================================================================

CVE-2026-74672	MODERATE	CHECK WITH IMPACT FROM ORIG NN MODERATE	Maybe valid. Check manually. Hints by AL-KERNEL: The best (paranoid) CVSS is 'AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H';*CWE-416;CWE-362;CWE-667;Other CVSS 'AV:L/AC:H/PR:H/UI:N/S:U/C:L/I:L/A:H';BEST CVSS score: '7';DESCR 'ptdump can walk kernel page tables it does not own while vmap huge mapping promotion can replace a lower level page table with a huge P4D PUD or PMD entry and free the old table. A race between these paths can let ptdump access a freed page table, resulting in use-after-free, memory corruption, or a kernel crash. For the CVSS the PR:L is used for the paranoid score because reliable triggering may be possible from a local user or less privileged service context if ptdump or related debug page table walking is exposed or invoked in the environment. The issue is not directly network reachable and requires local activity plus a timing window, so AC:H is appropriate. Impact is at least local denial of service and the UAF primitive makes limited or full confidentiality and integrity impact plausible enough for manual review.';YES REQUIRES MANUAL CHECK; ,and ActionableScore result is Strong Important candidate / Actionable Moderate at minimum (with actual score 5)	YES	WRITE OOB LOCK DEADLOCK DANGER INIT RACE UAF HARDWARE SYZBOT KPANIC MEMORY 	NO	NO	checked

======================================================================
ACTIONABLESCORE ANALYSIS
======================================================================

ActionableScore=7
ActionableScoreLower=3

## 1. ActionableScore

* Conservative score: 3
* Paranoid score: 7
* Final recommended bucket: **Strong Important candidate / Actionable Moderate at minimum**::

## 2. Signal breakdown

### Conservative score signals

* Generic memory corruption, UAF: +2
  The commit explicitly states that ptdump can access a freed page table after vmap promotes a lower page table into a huge P4D/PUD/PMD entry.

* Real lifetime corruption: +1
  The bug is a page table lifetime race where vmap frees a lower page table while ptdump may still be walking it.

* Reliable kernel crash / strong DoS: +1
  A stale page table walk can lead to UAF, invalid access, and kernel crash.

* Privileged high-value MMU/page-table path: +1
  The affected objects are kernel page tables and huge vmalloc mappings, which are high-value kernel memory-management structures.

* Hard or unreliable race / timing window: -1
  Triggering requires overlap between ptdump walking and vmap huge page table promotion/freeing.

* Requires admin/root/debug access in typical deployments: -2
  ptdump/debug page table walking is normally exposed only through privileged debugging interfaces.

Conservative total: 3

### Paranoid score signals

* Generic memory corruption, UAF: +2
* Real lifetime corruption: +1
* Reliable kernel crash / strong DoS: +1
* Privileged high-value MMU/page-table path: +1
* Confidentiality impact plausible: +1
  In the paranoid interpretation, a stale page table walk over reused memory may expose or process unintended kernel memory state through the debug walker.

* Integrity impact plausible: +1
  The affected state is kernel page-table metadata, and the commit explicitly describes memory corruption, even though no arbitrary write primitive is shown.

* Broad/core memory-management path: +1
  vmalloc huge mappings and kernel page-table manipulation are core kernel MM paths, even if ptdump itself is privileged/debug oriented.

* Hard or unreliable race / timing window: -1

Paranoid total: 7

No privilege-escalation bonus is awarded because the patch does not show attacker-controlled reclaim, object replacement, callback control, arbitrary write, or a demonstrated LPE primitive.

## 3. Reachability analysis

The practical trigger requires ptdump to walk kernel page tables while vmap concurrently promotes mappings to huge entries and frees the lower page table. In normal deployments, ptdump is usually a privileged debug path, so the conservative interpretation treats this as requiring root or equivalent debug access.

Namespaces and containers generally do not make this reachable to an ordinary unprivileged user unless the host exposes debugfs or ptdump-like functionality into a delegated environment. A reduced-capability root, container root, or service account with access to such debug interfaces should not be treated as full host-root for practical triage, which is why the paranoid score does not fully dismiss the issue.

The path is not network reachable. Realistic exploitation conditions require local activity, privileged or delegated debug access, huge vmap promotion, and a race window.

Call-site confidence: high. The commit message directly describes the relevant ptdump and vmap interaction, and the patch changes vmap_try_huge_pmd(), vmap_try_huge_pud(), vmap_try_huge_p4d(), and walk_page_range_debug() locking assertions.

## 4. Severity interpretation

This is not an ordinary Moderate cleanup because the patch fixes an explicit kernel UAF involving page table lifetime. The realistic demonstrated impact is closer to local privileged DoS, since the known trigger path is ptdump and no practical unprivileged exploit primitive is shown.

However, the affected objects are kernel page tables and the commit explicitly mentions UAF and memory corruption. For triage, this should be treated as at least Actionable Moderate and a Strong Important candidate under the paranoid interpretation. The main uncertainty is exploitability beyond crash, not whether a real lifetime bug exists.

## 5. One-sentence report phrase

A race between ptdump page-table walking and huge vmap page-table promotion can let ptdump access a freed lower-level page table, causing a kernel use-after-free and possible memory corruption, with practical reachability usually limited to local privileged or delegated debug access.

## 6. Manual review recommendation

MANUAL CHECK REQUIRED

Reason: explicit UAF plus memory corruption in kernel page-table handling is high-risk enough for manual review, even though the conservative practical trigger appears privileged and race-dependent.

======================================================================
UPSTREAM PATCH SUMMARY
======================================================================

Patch: mm/vmalloc: acquire init_mm lock on huge vmap to avoid ptdump UAF
Commit: c5bf8cd148cfea948cfa3db71da427294b20db0f
Upstream URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=c5bf8cd148cfea948cfa3db71da427294b20db0f

Commit description:

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
fa93b45 ("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 fa93b45 ("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)

[Commit description truncated; see the upstream URL below]

Changed files:
  mm/20260706203128.162335-1-devnexen
  include/linux/mmap_lock.h
  mm/pagewalk.c
  mm/vmalloc.c

Diff excerpt:

Not included in this email. See the upstream URL for the full patch.

Full patch:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=c5bf8cd148cfea948cfa3db71da427294b20db0f

======================================================================
DETAILED REPORT METHODOLOGY
======================================================================

The original Linux kernel CVE announcement for CVE-2026-74672 can be found here:
https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-74672

The original CVE announcement normally does not include a security-level
estimate. In particular, it may not contain a CVSS assessment, an impact
level, or enough information to determine whether the reported bug is a
practically relevant security issue. One purpose of this parallel CVE list
is to provide that missing technical and prioritization information.

The original goal of the AL-KERNEL project was to prioritize Linux kernel
CVE analysis automatically before manual review. The system can also help
identify non-security issues that may be suitable for automatic closure.

This report was generated by AL-KERNEL, an AI-assisted Linux kernel
vulnerability analysis system developed by Alexander Larkin.

The first analysis stage combines an autonomous classifier with additional
LLM-based analysis. The autonomous classifier runs locally on a CPU and is
based on a backpropagation neural network. Together, these mechanisms
produce a technical vulnerability description, identify likely weakness
types, estimate CVSS severity, and provide input for ActionableScore.

Two CVSS estimates are retained because incomplete kernel vulnerability
information often permits more than one defensible interpretation:

  Conservative CVSS vector: AV:L/AC:H/PR:H/UI:N/S:U/C:L/I:L/A:H
  The Best / paranoid CVSS vector: AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
  The Best / paranoid CVSS score: 7

The conservative vector represents a lower-impact interpretation.
The Best/paranoid vector intentionally represents a plausible upper-bound
interpretation and should not automatically be treated as demonstrated
real-world impact.

CVSS may also need to be adjusted for a particular Linux deployment,
because actual reachability, privileges, enabled kernel configuration,
hardware, namespaces, exposed device nodes, and other environmental
conditions can differ significantly between systems.

A separate ActionableScore mechanism evaluates practical remediation
urgency. Its analysis may include reachability, attack prerequisites,
subsystem exposure, memory-corruption characteristics, denial-of-service
reliability, and possible confidentiality, integrity, or
privilege-escalation impact.

  Conservative ActionableScore: 3
  Paranoid ActionableScore: 7

The final base severity is taken directly from the second tab-separated
field of the AL-KERNEL classification result. ActionableScore does not
replace or independently override that final AL-KERNEL decision, and
if ActionableScore adjusted impact level of ALKERNEL, then you would see
self-readable flags above like INCREASED_TO_HIGH_BASED_ON_ACTIONABLESCOREHIGHEREQTHAN7.

For an AL-KERNEL result of MODERATE, this report uses the following
additional presentation split:

  ActionableScore below 5   -> MODERATE REGULAR
  ActionableScore 5 or more -> MODERATE 7.0

The distinction between MODERATE REGULAR and MODERATE 7.0 makes it
possible to identify Moderate issues that should receive manual analysis
and fixes before lower-priority MODERATE REGULAR issues. In many cases,
MODERATE REGULAR fixes may wait for a later rebase or routine update.

There is one override in which MODERATE REGULAR becomes MODERATE 7.0
even when the ActionableScore is below 5. When the AL-KERNEL result
contains the KPANIC flag, a MODERATE result is always presented as
MODERATE 7.0. The KPANIC flag selected with few regexps without
usage of AI at all, so it helps to detect cases when Kernel Crash happens
and similar (to filter False-Negative results from the LLM usage).

KPANIC indicates that a reliable kernel crash, kernel panic, or similarly
serious kernel availability impact was identified by the classification
workflow.

AL-KERNEL base severity for this report: MODERATE
KPANIC detected for this report: YES
Published priority for this report (same as in Subject): MODERATE 7.0

These results are intended to support engineering triage. They are
machine-generated estimates, and cases marked for manual review should
be validated by a human security engineer before final disposition.
For more info read docs linked from here: https://kernelcve.org/
(and you can submit you own patch there to generate such a report
for non-existant CVE-id yet).

Note that in many cases this AI tool selects higher severity, than
real is (means you can expect Importants instead of Moderate 7.0 or
Moderates 7.0 instead of regular Moderates). If you see such cases,
please use reply email interface to add additional manual analyses
info to this particular CVE.
And please, please, let me know when you see Lows instead of Importants
or Important instead of Low (because particular for such cases I
need to tune this AI tool to make it better for this one and next similar).
My contact email for such notifications is alexanjelausa@gmail.com (and both
send reply to CVE record itself too and see "reply" button below for howto reply).