From mboxrd@z Thu Jan 1 00:00:00 1970 From: AL-KERNEL To: kernel-cve@kernelcve.org Subject: [CVE-2026-74632][MODERATE 7.0] mm/huge_memory: fix huge_zero_pfn race Date: Sat, 22 Aug 2026 16:30:35 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-AL-KERNEL-CVE: CVE-2026-74632 X-AL-KERNEL-Priority: MODERATE 7.0 X-AL-KERNEL-Severity: MODERATE 7.0 X-AL-KERNEL-Base-Severity: MODERATE X-AL-KERNEL-KPANIC: NO X-AL-KERNEL-ActionableScore: 6 X-AL-KERNEL-ActionableScore-Lower: 4 X-AL-KERNEL-Commit: 6024f6d0d9b9ca5138bfc4ac6f6e4bdf616e42b3 List-Id: 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).