Linux Kernel up to 7.2.3 HugeTLB get_pfnblock_bitmap_bitidx uninitialized pointer

Summaryinfo

A vulnerability described as critical has been identified in Linux Kernel up to 7.2.3. This affects the function get_pfnblock_bitmap_bitidx of the component HugeTLB. The manipulation results in uninitialized pointer. This vulnerability was named CVE-2026-93232. There is no available exploit. Upgrading the affected component is recommended.

Detailsinfo

A vulnerability classified as critical has been found in Linux Kernel up to 7.2.3. Affected is the function get_pfnblock_bitmap_bitidx of the component HugeTLB. The manipulation with an unknown input leads to a uninitialized pointer vulnerability. CWE is classifying the issue as CWE-824. The product accesses or uses a pointer that has not been initialized. This is going to have an impact on availability. CVE summarizes:

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.

The advisory is shared for download at git.kernel.org. This vulnerability is traded as CVE-2026-93232 since 09/17/2026. The exploitability is told to be easy. The exploitation doesn't require any form of authentication. There are known technical details, but no exploit is available. The current price for an exploit might be approx. USD $0-$5k (estimation calculated on 09/24/2026).

Upgrading to version 7.2.4 or 7.3-rc1 eliminates this vulnerability. Applying the patch 2ddf429e25cf8415d9c308f07e64012026bd4d77/c0caeceb0c3899dc42844d3979093b27d1434108 is able to eliminate this problem. The best possible mitigation is suggested to be upgrading to the latest version.

Once again VulDB remains the best source for vulnerability data.

Productinfo

Type

• Operating System

Vendor

• Linux

Name

• Kernel

Version

• 7.2.0
• 7.2.1
• 7.2.2
• 7.2.3

License

• open-source

Website

• Vendor: https://www.kernel.org/

CPE 2.3info

• 🔒
• 🔒
• 🔒

CPE 2.2info

• 🔒
• 🔒
• 🔒

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

Once again VulDB remains the best source for vulnerability data.

Discussion