CVE-2026-74632 - Vulnerability Details

- mm/huge_memory: fix huge_zero_pfn race

Description

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

mm/huge_memory: fix huge_zero_pfn race

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
gated on zero huge_zero_refcount.

The fast path doesn't use huge_zero_lock, so the critical section is
irrelevant to it.

So invariants are required - huge_zero_refcount MUST:

* Only be set in the huge_zero_lock critical section to ensure
serialisation of huge_zero_pfn, huge_zero_folio and
---truncated---

Published: 2026-08-22

Score: n/a

EPSS: n/a

KEV: No

Impact:

Action:

Analysis

Impact

A subtle race between the shrinker and the get_huge_zero_folio routine can overwrite the huge_zero_pfn value with a sentinel value while a valid huge_zero_folio remains. This causes the kernel to mistakenly treat a huge zero page as an ordinary transparent huge page, leading to incorrect paging operations such as splitting or misdirected page faults, which may corrupt kernel memory and destabilize the system.

Affected Systems

All Linux kernel builds prior to inclusion of the patch series "mm/huge_memory: fix huge_zero_pfn race" are potentially affected. The exact version range is not specified in the provided data.

Risk and Exploitability

No CVSS or EPSS score is available, and the vulnerability is not listed in the CISA KEV catalog. The attack vector requires concurrent activity between the kernel’s shrinker and page fault handlers, which makes exploitation difficult but not impossible on heavily loaded systems. The lack of a publicly disclosed exploit and the complexity of reproducing the race suggest a moderate risk that should be mitigated by updating the kernel.

Default status is the baseline for the product, each version can override it (e.g. patched versions marked unaffected).

Vendor Product Default status Versions

Linux

unaffected

Version	Status	Constraints
`3b77e8c8cde581dadab9a0f1543a347e24315f11`	affected	< 6024f6d0d9b9ca5138bfc4ac6f6e4bdf616e42b3
`3b77e8c8cde581dadab9a0f1543a347e24315f11`	affected	< 105d04edbec83010df5728f74d17fd9c108e7553
`3b77e8c8cde581dadab9a0f1543a347e24315f11`	affected	< ab7e4b407c7f58d1a003134eff3841f303d5ccc2
`3b77e8c8cde581dadab9a0f1543a347e24315f11`	affected	< 33192a26cddea7a7e4ca66e5c3eebd36fa8be2bb
`fc1fbc5b017b6f5ef24a4a93f33cd022225e01c8`	affected	—
`bd092a0f19423d7e9e81182314a96ecd6a14f3b7`	affected	—
`6527d8ef68c3ca3c455e38ae2a37cd7810caec73`	affected	—
`b1daf8f862136894a4595770a44e4508808fb806`	affected	—
`4.19.197`	affected	< 4.20
`5.4.129`	affected	< 5.5
`5.10.47`	affected	< 5.11
`5.12.14`	affected	< 5.13

Linux

affected

Version	Status	Constraints
`5.13`	affected	—
`0`	unaffected	< 5.13
`6.12.104`	unaffected	≤ 6.12.*
`6.18.45`	unaffected	≤ 6.18.*
`7.1.9`	unaffected	≤ 7.1.*
`7.2`	unaffected	≤ *

No data.

Vendor Product Confidence Versions

Linux

Linux Kernel

99%

Version	Status	Scheme	Platform
`[3b77e8c8cde581dadab9a0f1543a347e24315f11,6024f6d0d9b9ca5138bfc4ac6f6e4bdf616e42b3)`	affected	code_commit	—
`[3b77e8c8cde581dadab9a0f1543a347e24315f11,105d04edbec83010df5728f74d17fd9c108e7553)`	affected	code_commit	—
`[3b77e8c8cde581dadab9a0f1543a347e24315f11,ab7e4b407c7f58d1a003134eff3841f303d5ccc2)`	affected	code_commit	—
`[3b77e8c8cde581dadab9a0f1543a347e24315f11,33192a26cddea7a7e4ca66e5c3eebd36fa8be2bb)`	affected	code_commit	—
`fc1fbc5b017b6f5ef24a4a93f33cd022225e01c8`	affected	code_commit	—
`bd092a0f19423d7e9e81182314a96ecd6a14f3b7`	affected	code_commit	—
`6527d8ef68c3ca3c455e38ae2a37cd7810caec73`	affected	code_commit	—
`b1daf8f862136894a4595770a44e4508808fb806`	affected	code_commit	—
`[4.19.197,4.20)`	affected	semver	—
`[5.4.129,5.5)`	affected	semver	—
`[5.10.47,5.11)`	affected	semver	—
`[5.12.14,5.13)`	affected	semver	—

Linux

Linux Kernel

99%

Version	Status	Scheme	Platform
`5.13`	affected	generic	—
`[0,5.13)`	unaffected	generic	—
`[6.12.104,7.0.0)`	unaffected	semver	—
`[6.18.45,7.0.0)`	unaffected	semver	—
`[7.1.9,8.0.0)`	unaffected	semver	—
`[7.2,*]`	unaffected	generic	—

Found an issue or want to improve our Enrichment? You can suggest it directly by opening an issue on our dedicated GitHub repository .

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

Install a Linux kernel release that includes the "mm/huge_memory: fix huge_zero_pfn race" patch series (commit 105d04ed...).
If an update is not immediately possible, disable transparent hugepages temporarily (e.g., echo never > /sys/kernel/mm/transparent_hugepage/enabled).
After applying the update, monitor dmesg and kernel logs for THP-related errors to confirm the issue has been resolved.

Generated by OpenCVE AI on August 22, 2026 at 18:36 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

No CVSS v4.0

No CVSS v3.1

No CVSS v3.0

No CVSS v2

This CVE is not in the KEV list.

No EPSS score available.

Key SSVC decision points have not yet been added.

References

Link	Providers
https://git.kernel.org/stable/c/105d04edbec83010df5728f74d17fd9c108e7553
https://git.kernel.org/stable/c/33192a26cddea7a7e4ca66e5c3eebd36fa8be2bb
https://git.kernel.org/stable/c/6024f6d0d9b9ca5138bfc4ac6f6e4bdf616e42b3
https://git.kernel.org/stable/c/ab7e4b407c7f58d1a003134eff3841f303d5ccc2

History

Sat, 22 Aug 2026 19:00:00 +0000

Type	Values Removed	Values Added
Weaknesses		CWE-362

Sat, 22 Aug 2026 15:45:00 +0000

Type	Values Removed	Values Added
Description		In the Linux kernel, the following vulnerability has been resolved: mm/huge_memory: fix huge_zero_pfn race 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 gated on zero huge_zero_refcount. The fast path doesn't use huge_zero_lock, so the critical section is irrelevant to it. So invariants are required - huge_zero_refcount MUST: * Only be set in the huge_zero_lock critical section to ensure serialisation of huge_zero_pfn, huge_zero_folio and ---truncated---
Title		mm/huge_memory: fix huge_zero_pfn race
First Time appeared		Linux Linux linux Kernel
CPEs		cpe:2.3:o:linux:linux_kernel::::::::
Vendors & Products		Linux Linux linux Kernel
References		https://git.kernel.org/stable/c/105d04edbec83010df5728f74d17fd9c108e7553 https://git.kernel.org/stable/c/33192a26cddea7a7e4ca66e5c3eebd36fa8be2bb https://git.kernel.org/stable/c/6024f6d0d9b9ca5138bfc4ac6f6e4bdf616e42b3 https://git.kernel.org/stable/c/ab7e4b407c7f58d1a003134eff3841f303d5ccc2

Subscriptions

Linux Linux Kernel

MITRE

Status: PUBLISHED

Assigner: Linux

Published: 2026-08-22T15:32:13.078Z

Updated: 2026-08-22T15:32:13.078Z

Reserved: 2026-08-15T05:44:03.922Z

Link: CVE-2026-74632

Vulnrichment

No data.

NVD

Status : Received

Published: 2026-08-22T16:16:36.217

Modified: 2026-08-22T16:16:36.217

Link: CVE-2026-74632

Redhat

No data.

OpenCVE Enrichment

Updated: 2026-08-22T21:30:16Z

Weaknesses

CWE-362
Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')

Impact

Affected Systems

Risk and Exploitability

Tracking

Subscriptions

JSON object

JSON object

JSON object

JSON object

JSON object