CVE-2026-93232 in Linux
Summary
by MITRE • 09/24/2026
In the Linux kernel, the following vulnerability has been resolved:
mm/hugetlb: fix boot panic with CONFIG_DEBUG_VM and HVO bootmem pages
Patch series "mm: Refactor bootmem gigantic hugepage allocation", v4.
This series is split out from the earlier larger series "mm: Generalize HVO for HugeTLB and device DAX" [1]. It collects the first 19 patches of
that series as a standalone set of fixes and preparatory cleanups around bootmem HugeTLB handling, sparse initialization ordering, and related vmemmap setup.
The first patches fix a few bugs found while reviewing the existing code, including incorrect bootmem HVO handling, wrong vmemmap registration arguments, a powerpc compound-vmemmap tracking bug, and too-late initialization of gigantic bootmem HugeTLB struct pages.
The rest of the series reorders early memory initialization so the relevant zone state is available before sparse and HugeTLB boot-time setup runs, then simplifies the remaining bootmem gigantic hugepage allocation path and removes code made obsolete by that rework.
At a high level: - patches [1-4] fix boot-time and arch-specific bugs
- patches [5-12] reorder and simplify sparse/mm/hugetlb early init
- patches [13-19] refactor bootmem gigantic hugepage allocation and
remove obsolete helpers and state
This patch (of 19):
Commit 622026e87c40 ("mm/hugetlb: remove fake head pages") switched HVO to reuse per-zone shared tail pages from zone->vmemmap_tails[].
Those shared tail pages were initialized in hugetlb_vmemmap_init(), but bootmem HugeTLB folios are prepared earlier from gather_bootmem_prealloc(). With hugetlb_free_vmemmap=on, prep_and_add_bootmem_folios() can access pageblock flags on bootmem HugeTLB pages whose mirrored tail struct pages already point to the shared tail page. On CONFIG_DEBUG_VM kernels, get_pfnblock_bitmap_bitidx() then dereferences the still-uninitialized shared tail page and can panic during boot.
Initialize zone->vmemmap_tails[] from gather_bootmem_prealloc(), before
bootmem HugeTLB folios are processed, and drop the later initialization from hugetlb_vmemmap_init().
This bug only affects CONFIG_DEBUG_VM kernels, where the relevant assertion is evaluated.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/24/2026
The Linux kernel vulnerability identified in this context involves a critical boot-time panic triggered within the memory management subsystem when specific configuration options are enabled. The issue arises from an incorrect initialization ordering of shared tail pages used for HugeTLB Virtual Memory Overcommit (HVO) handling, specifically affecting systems configured with CONFIG_DEBUG_VM and HVO-enabled gigantic hugepage support. This flaw was addressed through a patch series that refactors bootmem gigantic hugepage allocation to ensure proper sequencing of early memory initialization routines. The root cause lies in the fact that shared tail pages within zone->vmemmap_tails were initialized too late, after bootmem HugeTLB folios had already been prepared by gather_bootmem_prealloc(). Consequently, when hugetlb_free_vmemmap is enabled, the prep_and_add_bootmem_folios function accesses pageblock flags on bootmem HugeTLB pages. These pages have mirrored tail struct pages that point to shared tail pages which are still uninitialized. Under CONFIG_DEBUG_VM conditions, this leads get_pfnblock_bitmap_bitidx() to dereference an invalid memory structure, resulting in a kernel panic during the early boot process before the operating system can fully initialize.
From a technical perspective, this vulnerability represents a classic initialization race condition or ordering error within the kernel's virtual memory map management code. The HugeTLB subsystem relies on shared tail pages to optimize memory usage for large pages, but these structures must be valid before any component attempts to reference them. By moving the initialization of zone->vmemmap_tails[] into gather_bootmem_prealloc(), the patch ensures that all necessary metadata is ready prior to processing bootmem HugeTLB folios. This reordering aligns with best practices for kernel memory management, where dependent subsystems must be initialized in a strict dependency chain to prevent access to undefined or null pointers. The fix also involves removing obsolete code from hugetlb_vmemmap_init(), thereby simplifying the overall architecture and reducing the attack surface by eliminating redundant initialization paths that could potentially introduce similar errors in future modifications.
The operational impact of this vulnerability is severe for affected systems, as it prevents successful booting when CONFIG_DEBUG_VM is enabled alongside HVO gigantic hugepage support. While CONFIG_DEBUG_VM is primarily intended for development and debugging purposes to catch memory corruption issues early, its presence does not negate the severity of a kernel panic that halts system startup. For production environments where this configuration might be inadvertently left on or tested during deployment phases, the result is a complete denial of service due to inability to reach an operational state. Although the bug specifically targets debug kernels, it highlights underlying fragility in the bootmem initialization sequence that could potentially manifest under other conditions if not properly corrected. The vulnerability affects system availability and reliability, particularly in high-performance computing or specialized server environments where gigantic hugepages are utilized for performance optimization.
This issue can be categorized under CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization, as it involves improper sequencing of resource initialization leading to invalid state access. Additionally, the failure mode aligns with CWE-824: Access of Uninitialized Pointer, since get_pfnblock_bitmap_bitidx() attempts to dereference a pointer that has not been properly initialized by the time it is called. In terms of MITRE ATT&CK mapping, while this is primarily an internal stability issue rather than an exploitable remote vulnerability, it relates to TA0004: Privilege Escalation and TA0005: Defense Evasion in a broad sense because kernel panics can be leveraged for denial-of-service attacks if triggered by local users with sufficient privileges. However, given its nature as a boot-time crash dependent on specific debug configurations, it is more accurately viewed as a reliability defect rather than a direct security exploit vector.
Mitigation strategies primarily involve applying the provided patch series to update the Linux kernel memory management subsystem. Administrators should ensure that their systems are running patched versions of the kernel where gather_bootmem_prealloc correctly initializes zone->vmemmap_tails[] before bootmem HugeTLB folios are processed. For environments requiring CONFIG_DEBUG_VM, this fix is essential for maintaining system stability during development and testing phases. In production settings, it is recommended to disable CONFIG_DEBUG_VM unless absolutely necessary for debugging specific memory issues, as its overhead can impact performance and exposes the kernel to additional assertion checks that may trigger on edge cases. Regularly updating kernels with upstream fixes ensures that such initialization ordering bugs are resolved before they can cause operational disruptions. Furthermore, code reviews focusing on early boot sequence dependencies should be conducted to prevent similar synchronization errors in other subsystems like sparse memory handling or vmemmap setup procedures.