CVE-202 6-74632: Linux Kernel Race Condition Vulnerability

CVE-2026-74632 Overview

CVE-2026-74632 is a race condition in the Linux kernel's transparent huge page (THP) subsystem, specifically in the reference-counted huge_zero_folio implementation within mm/huge_memory. The fast-path atomic logic fails to serialize writes to huge_zero_pfn between get_huge_zero_folio() and shrink_huge_zero_folio_scan(). When the shrinker drops the final huge_zero_refcount pin, it can overwrite huge_zero_pfn with the ~0UL sentinel value after a racing allocator installed a valid PFN. The result is a state where huge_zero_folio is valid but huge_zero_pfn is invalid, causing is_huge_zero_pfn() and is_huge_zero_pmd() to misidentify the huge zero folio as an ordinary THP folio.

Critical Impact
A local attacker able to trigger concurrent page faults and shrinker activity can force the kernel to split or otherwise mishandle the huge zero folio, leading to memory corruption or denial of service on affected systems.

Affected Products

Linux kernel versions with the reference-counted huge_zero_folio implementation in mm/huge_memory
Systems built without CONFIG_PERSISTENT_HUGE_ZERO_FOLIO
Weakly ordered architectures where load/store reordering exacerbates the race window

Discovery Timeline

2026-08-22 - CVE-2026-74632 published to NVD
2026-08-27 - Last updated in NVD database

Technical Details for CVE-2026-74632

Vulnerability Analysis

The defect is a race condition [CWE-362] in the Linux kernel memory management code that handles the huge zero page. When CONFIG_PERSISTENT_HUGE_ZERO_FOLIO is not set, the kernel refcounts the huge zero folio using huge_zero_refcount and returns it through mm_get_huge_zero_folio(). Only the shrinker can drop the refcount to zero.

A race arises when shrink_huge_zero_folio_scan() is preempted between setting huge_zero_refcount to zero and writing the sentinel value into huge_zero_pfn. During this preemption window, a concurrent get_huge_zero_folio() call observes zero via atomic_inc_not_zero(), allocates a new huge zero folio, and writes valid values into both huge_zero_folio and huge_zero_pfn. When the shrinker resumes, it overwrites the freshly written huge_zero_pfn with ~0UL, leaving the kernel with a valid folio pointer but an invalid PFN.

Root Cause

The root cause is missing serialization between the shrinker's teardown sequence and the allocator's fast path. get_huge_zero_folio() uses cmpxchg() gated on huge_zero_folio being NULL, while shrink_huge_zero_folio_scan() uses xchg() and a separate atomic to update huge_zero_refcount. Because huge_zero_pfn is not covered by the same atomic sequence, its write can be reordered against the folio pointer update, particularly on weakly ordered architectures.

Attack Vector

Exploitation requires local access with the ability to generate concurrent memory pressure and page faults that touch huge zero mappings. An unprivileged local process can trigger repeated allocation and reclaim of the huge zero folio to widen the race window. Once is_huge_zero_pmd() returns false for a legitimate huge zero mapping, the THP code path splits the folio incorrectly, which can corrupt page tables and destabilize the kernel.

No verified public exploit code is available. The upstream fix introduces a huge_zero_lock spinlock that serializes writes to huge_zero_folio, huge_zero_pfn, and huge_zero_refcount, with careful load/store ordering preserved for the atomic fast path. See the kernel patch series for the full implementation.

Detection Methods for CVE-2026-74632

Indicators of Compromise

Unexpected kernel warnings or BUGs originating from mm/huge_memory.c, particularly in code paths that call is_huge_zero_pmd() or split THP folios.
Kernel oops or page-table corruption traces referencing split_huge_page, __split_huge_pmd, or mm_get_huge_zero_folio.
Repeated dmesg entries showing THP splits on mappings that should resolve to the shared huge zero folio.

Detection Strategies

Inventory running kernels against the fixed commits listed in the NVD references and flag hosts still on vulnerable builds.
Correlate kernel crash telemetry with workloads that heavily exercise THP, such as databases, JVMs, and analytics engines using large anonymous mappings.
Monitor for unprivileged processes that combine aggressive madvise(MADV_HUGEPAGE) usage with sustained memory pressure that forces shrinker activity.

Monitoring Recommendations

Ship kernel logs and crash dumps to a centralized analytics pipeline and alert on repeated faults in huge_memory symbols.
Track /sys/kernel/mm/transparent_hugepage/ state and shrinker counters for anomalous churn on the huge zero folio.
Alert on any local user process that generates high volumes of THP allocation and reclaim cycles outside expected workloads.

How to Mitigate CVE-2026-74632

Immediate Actions Required

Apply the upstream stable kernel updates that include the huge_zero_lock fix and rebuild or redeploy affected hosts.
Prioritize patching multi-tenant systems and hosts exposing local shell access to untrusted users, where the local attack vector is most relevant.
Verify that vendor kernel packages incorporate the referenced fix commits before rolling out to production fleets.

Patch Information

The Linux kernel maintainers merged the fix across multiple stable branches. Relevant commits include 105d04ed, 33192a26, 6024f6d0, 9332b080, 9c0fd180, ab7e4b40, b7041ba6, and f3a874a9. Refer to the Linux stable kernel patch index and coordinate with your distribution vendor for backported packages.

Workarounds

Build with CONFIG_PERSISTENT_HUGE_ZERO_FOLIO where feasible, which avoids the shrinker teardown path that races with allocation.
Disable transparent huge pages system-wide by setting transparent_hugepage=never on the kernel command line when patching cannot be scheduled immediately.
Restrict local access to trusted users and constrain workloads that can drive sustained THP allocation and reclaim churn.

bash

# Temporarily disable THP to remove the race surface until patched
echo never > /sys/kernel/mm/transparent_hugepage/enabled
echo never > /sys/kernel/mm/transparent_hugepage/defrag

# Verify installed kernel includes the fix
uname -r
grep -E 'huge_zero_lock' /proc/kallsyms || echo "Fix symbol not present - patch required"