CVE-2026-74632
- Source
- https://cve.org/CVERecord?id=CVE-2026-74632
- Import Source
- https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-74632.json
- JSON Data
- https://api.osv.dev/v1/vulns/CVE-2026-74632
- Downstream
- Published
- 2026-08-22T15:32:13.078Z
- Modified
- 2026-08-23T03:53:40.442847281Z
- Summary
- mm/huge_memory: fix huge_zero_pfn race
- Details
-
In the Linux kernel, the following vulnerability has been resolved:
mm/hugememory: fix hugezero_pfn race
Patch series "mm/hugememory: fix hugezero_pfn race", v2.
There is a subtle race in the reference-counted hugezerofolio implementation.
The fast path atomic logic fails to account for the fact that the shrinker (which drops the final hugezerorefcount pin) can overwrite hugezeropfn with the ~0UL sentinel value in shrinkhugezerofolioscan() after a racing gethugezero_folio() installed a valid value there.
This results in hugezerofolio being correctly set but hugezeropfn being set incorrectly and thus ishugezeropfn() and consequently ishugezeropmd() 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 hugezero[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 CONFIGPERSISTENTHUGEZEROFOLIO logic to better separate the persistent logic from the dynamically allocated one.
This patch (of 2):
If !CONFIGPERSISTENTHUGEZEROFOLIO, the hugezerofolio is refcounted by hugezerorefcount and returned by mmgethugezerofolio().
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 shrinkhugezerofolioscan() might, if very unlucky, be preempted between setting hugezerorefcount to zero and writing an invalid value.
During this time gethugezerofolio() could write to hugezeropfn before shrinkhugezerofolio_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=======================================|================================= shrinkhugezerofolioscan() | atomiccmpxchg() sets refcount to 0 | xchg() sets hugezerofolio to NULL | gethugezerofolio() | | atomicincnotzero() -> zero preempted for a long time | Allocate new huge zero folio | | Write valid hugezerofolio v | Write valid hugezeropfn Overwrite hugezero_pfn with ~0UL <--- Invalid overwrite!
This results in ishugezeropfn() and ishugezeropmd() 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 hugezeropfn not hugezerofolio, as gethugezerofolio() uses cmpxchg() gated on hugezerofolio being NULL with a retry loop and shrinkhugezerofolioscan() uses xchg() to set hugezero_folio.
Fix the issue by introducing a spinlock, hugezerolock, to prevent concurrent write of hugezerofolio, hugezeropfn and hugezerorefcount.
There needs to be significant care taken here to ensure correctness:
The fast path in gethugezerofolio() uses atomicincnotzero(), which is outside of the critical section, and means huge zero allocation is gated on zero hugezerorefcount.
The fast path doesn't use hugezerolock, so the critical section is irrelevant to it.
So invariants are required - hugezerorefcount MUST:
- Only be set in the hugezerolock critical section to ensure serialisation of hugezeropfn, hugezerofolio and ---truncated---
- Database specific
{ "cna_assigner": "Linux", "osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/74xxx/CVE-2026-74632.json" }- References
-
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
- 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
- https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/74xxx/CVE-2026-74632.json
- https://nvd.nist.gov/vuln/detail/CVE-2026-74632
Affected packages
Git / git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Affected ranges
- Type
- GIT
- Repo
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
- Events
-
Introduced3b77e8c8cde581dadab9a0f1543a347e24315f11Fixed6024f6d0d9b9ca5138bfc4ac6f6e4bdf616e42b3Fixed105d04edbec83010df5728f74d17fd9c108e7553Fixedab7e4b407c7f58d1a003134eff3841f303d5ccc2Fixed33192a26cddea7a7e4ca66e5c3eebd36fa8be2bb
- Type
- GIT
- Repo
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
- Events
-
Introduced0 Unknown introduced commit / All previous commits are affectedLast affectedfc1fbc5b017b6f5ef24a4a93f33cd022225e01c8Last affectedbd092a0f19423d7e9e81182314a96ecd6a14f3b7Last affected6527d8ef68c3ca3c455e38ae2a37cd7810caec73Last affectedb1daf8f862136894a4595770a44e4508808fb806
- Type
- GIT
- Repo
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
- Events
-
Introduced4.19.197Fixed4.20
- Type
- GIT
- Repo
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
- Events
-
Introduced5.4.129Fixed5.5
- Type
- GIT
- Repo
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
- Events
-
Introduced5.10.47Fixed5.11
- Type
- GIT
- Repo
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
- Events
-
Introduced5.12.14Fixed5.13