[CVE-2026-74632][MODERATE 7.0] mm/huge_memory: fix huge_zero_pfn race

[CVE-2026-74632][MODERATE 7.0] mm/huge_memory: fix huge_zero_pfn race

[AL-KERNEL]

CVE: CVE-2026-74632
Priority: MODERATE 7.0
AL-KERNEL base severity: MODERATE
KPANIC flag: NO
Patch: mm/huge_memory: fix huge_zero_pfn race
Commit: 6024f6d0d9b9ca5138bfc4ac6f6e4bdf616e42b3
Upstream patch: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=6024f6d0d9b9ca5138bfc4ac6f6e4bdf616e42b3
Original CVE announcement: https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-74632
Analysis date: Sat, 22 Aug 2026 16:30:35 -0400
ActionableScore: 6
ActionableScore lower bound: 4
Actionable bucket: Strong Important candidate / Actionable Moderate at minimum
Manual review required: YES

Summary:
A race in huge zero folio state management can leave huge_zero_folio valid while huge_zero_pfn is reset to an invalid sentinel, causing THP code to misidentify and incorrectly process the huge zero folio with potential local DoS and possible memory corruption impact.

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

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

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-74632	MODERATE	CHECK WITH IMPACT FROM ORIG NN IMPORTANT	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-362;*CWE-664;*CWE-416;Other CVSS 'AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H';BEST CVSS score: '7';DESCR 'The huge zero folio state can become inconsistent because shrink_huge_zero_folio_scan() may overwrite huge_zero_pfn with the invalid sentinel after a racing get_huge_zero_folio() installed a new valid huge_zero_folio and pfn. As a result, is_huge_zero_pfn() and is_huge_zero_pmd() may fail to recognize the huge zero folio and later THP code can treat it as an ordinary transparent huge page, including paths that may split or otherwise modify it incorrectly. For the CVSS the PR:L is used because a local unprivileged process can plausibly participate in the page fault side by creating mappings that use huge zero pages, while the race also depends on shrinker or memory pressure timing. The issue is not network reachable and AC:H is used because the bug requires a narrow race window between shrinker teardown and a concurrent page fault. Impact is at least local denial of service via kernel crash or memory management corruption, and the paranoid score treats the incorrect THP handling as a plausible privilege escalation candidate requiring 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 RACE HARDWARE MEMORY  DECREASED_TO_MODERATE70_BASED_ON_ACTIONABLESCORELOWERTHAN6 DECREASED_TO_MODERATEREG_BASED_ON_FALSEPOSCHECKOFKP	NO	NO	checked

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

ActionableScore=6
ActionableScoreLower=4

## 1. ActionableScore

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

## 2. Signal breakdown

Conservative score:

* Local unprivileged trigger: +1
  A local process can plausibly participate in the page fault side by creating memory mappings that use huge zero pages. No admin capability is clearly required for that side of the race.
* Memory corruption, weak/indirect corruption candidate: +1
  The bug does not show an arbitrary write or controlled UAF reclaim, but it can make THP code misinterpret a huge zero folio as an ordinary THP folio.
* Real lifetime/refcount state corruption: +1
  The patch fixes inconsistent updates across huge_zero_folio, huge_zero_pfn, and huge_zero_refcount. This is a real lifetime/state invariant bug in core memory management.
* Broad/default/common subsystem: +1
  This is in core mm/THP huge zero folio handling, not a narrow driver-only path.
* Availability impact realistic: +1
  Incorrectly splitting or otherwise treating the huge zero folio as a normal THP can plausibly crash or destabilize the kernel.
* Hard or unreliable race / special timing required: -1
  The trigger requires a race between shrink_huge_zero_folio_scan() and a concurrent page fault, with unlucky preemption or timing.

Conservative total: 4

Paranoid additional signals:

* Weak LPE concern: +1
  The bug creates an invalid object interpretation in core MM. There is no demonstrated reclaim or arbitrary write primitive, but incorrect THP handling of a special global folio is enough to justify manual LPE review.
* Memory layout / invariant restoration: +1
  The patch serializes and orders updates to multiple interdependent state variables: huge_zero_folio, huge_zero_pfn, and huge_zero_refcount.

Paranoid total: 6

## 3. Reachability analysis

A local unprivileged user may be able to influence the page fault side by creating mappings that use huge zero pages, while the shrinker side depends on memory pressure and reclaim timing. The issue is not network reachable. Containers and namespaces may not remove the risk if the workload can create memory pressure and trigger relevant page faults, but they do not by themselves provide a stronger exploit primitive.

The affected path depends on dynamic huge zero folio behavior with !CONFIG_PERSISTENT_HUGE_ZERO_FOLIO and THP huge zero page use. Triggering is timing dependent and likely not fully reliable without stress conditions. Call-site confidence: medium high, because the patch and commit describe the affected state transitions and downstream misclassification, but do not provide a concrete crash trace or exploit primitive.

## 4. Severity interpretation

This is stronger than an ordinary Moderate correctness fix because it affects core memory-management state and can cause incorrect THP handling of a huge zero folio. Realistic demonstrated impact is closest to local DoS or kernel memory-management corruption under a difficult race. Theoretical privilege escalation is plausible enough for manual review, but not proven because the patch does not show controlled reclaim, arbitrary write, attacker-selected object replacement, or a direct type-confusion exploit path.

Overall this should be treated as Actionable Moderate at minimum, with Strong Important candidate attention if the affected product configuration commonly enables the vulnerable huge zero folio mode.

## 5. One-sentence report phrase

A race in huge zero folio state management can leave huge_zero_folio valid while huge_zero_pfn is reset to an invalid sentinel, causing THP code to misidentify and incorrectly process the huge zero folio with potential local DoS and possible memory corruption impact.

## 6. Manual review recommendation

MANUAL CHECK REQUIRED

Core MM race conditions with refcounted folio state and incorrect THP object classification have historically been easy to underestimate. The current evidence supports at least local DoS, and the paranoid score keeps this in the manual-review path due to plausible but unproven memory corruption or privilege escalation consequences.

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

Patch: mm/huge_memory: fix huge_zero_pfn race
Commit: 6024f6d0d9b9ca5138bfc4ac6f6e4bdf616e42b3
Upstream URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=6024f6d0d9b9ca5138bfc4ac6f6e4bdf616e42b3

Commit description:

Patch series "mm/huge_memory: fix huge_zero_pfn race", v2.

There is a subtle race in the reference-counted huge_zero_folio
implementation.

The fast path atomic logic fails to account for the fact that the shrinker
(which drops the final huge_zero_refcount pin) can overwrite huge_zero_pfn
with the ~0UL sentinel value in shrink_huge_zero_folio_scan() after a
racing get_huge_zero_folio() installed a valid value there.

This results in huge_zero_folio being correctly set but huge_zero_pfn
being set incorrectly and thus is_huge_zero_pfn() and consequently
is_huge_zero_pmd() will misidentify the huge zero folio as being an
ordinary THP folio.

This can result in the huge zero folio being split and otherwise treated
incorrectly.

The solution to this is very subtle as there is an atomic fast path, and
thus ordering in weakly ordered architectures has to be treated very
carefully.

The first commit fixes the issue by introducing a spinlock around
huge_zero_[pfn, folio, refcount] write, with careful consideration paid to
load/store ordering in the fast path.  It is placed first and kept as
small as possible so that it can be backported on its own.

The second commit is a pure cleanup which reworks the
CONFIG_PERSISTENT_HUGE_ZERO_FOLIO logic to better separate the persistent
logic from the dynamically allocated one.

This patch (of 2):

If !CONFIG_PERSISTENT_HUGE_ZERO_FOLIO, the huge_zero_folio is refcounted
by huge_zero_refcount and returned by mm_get_huge_zero_folio().

When the caller is done with the huge zero page, its reference count is
decremented.  Only a shrinker can set the reference count to zero.

A race can unfortunately occur between a shrinker decrementing the
reference count to zero and a concurrent page fault.

This is because shrink_huge_zero_folio_scan() might, if very unlucky, be
preempted between setting huge_zero_refcount to zero and writing an
invalid value.

During this time get_huge_zero_folio() could write to huge_zero_pfn before
shrink_huge_zero_folio_scan() resumes.

In this event the huge zero folio will be persistently misidentified
causing the THP code path to be entered inappropriately for the huge zero
folio:

                CPU 0                                   CPU 1
=======================================|=================================
shrink_huge_zero_folio_scan()          |
   atomic_cmpxchg() sets refcount to 0 |
   xchg() sets huge_zero_folio to NULL | get_huge_zero_folio()
                 |                     |    atomic_inc_not_zero() -> zero
      preempted for a long time        |    Allocate new huge zero folio
                 |                     |    Write valid huge_zero_folio
                 v                     |    Write valid huge_zero_pfn
  Overwrite huge_zero_pfn with ~0UL   <--- Invalid overwrite!

This results in is_huge_zero_pfn() and is_huge_zero_pmd() incorrectly
returning false for a huge zero page which could result in issues like the
huge zero folio being incorrectly split.

Note that the issue is with huge_zero_pfn not huge_zero_folio, as
get_huge_zero_folio() uses cmpxchg() gated on huge_zero_folio being NULL
with a retry loop and shrink_huge_zero_folio_scan() uses xchg() to set
huge_zero_folio.

Fix the issue by introducing a spinlock, huge_zero_lock, to prevent
concurrent write of huge_zero_folio, huge_zero_pfn and huge_zero_refcount.

There needs to be significant care taken here to ensure correctness:

The fast path in get_huge_zero_folio() uses atomic_inc_not_zero(), which
is outside of the critical section, and means huge zero allocation is

[Commit description truncated; see the upstream URL below]

Changed files:
  mm/20260727154001.4102341-1-uqbarz
  mm/huge_memory.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=6024f6d0d9b9ca5138bfc4ac6f6e4bdf616e42b3

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

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

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:L/UI:N/S:U/C:N/I:N/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: 4
  Paranoid ActionableScore: 6

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: NO
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).