Katalog CVE

CVE-2026-93232

Nieznane
Opublikowano: Przetłumaczono: NVD NIST

Streszczenie

W jądrze Linux wykryto podatność powodującą panikę podczas bootowania w konfiguracji CONFIG_DEBUG_VM z włączoną opcją hugetlb_free_vmemmap. Problem dotyczy inicjalizacji współdzielonych stron ogonowych (zone->vmemmap_tails[]) używanych przez HVO, które są przygotowywane zbyt późno, co prowadzi do dereferencji niezainicjalizowanej strony i paniki. Poprawka przenosi inicjalizację do gather_bootmem_prealloc(), przed przetwarzaniem foliów HugeTLB z bootmem.

Ocena ryzyka

Ryzyko dotyczy systemów z włączonym CONFIG_DEBUG_VM i hugetlb_free_vmemmap, gdzie podczas uruchamiania może wystąpić panika jądra, uniemożliwiając start systemu. Atakujący nie może bezpośrednio wykorzystać tej podatności, ale awaria usługi (DoS) może wystąpić w środowiskach z dużymi stronami HugeTLB.

Rekomendacja

Zaleca się aktualizację jądra Linux do wersji zawierającej poprawkę (commit 622026e87c40 i powiązane zmiany). Jeśli aktualizacja nie jest możliwa, tymczasowo wyłącz opcję hugetlb_free_vmemmap lub CONFIG_DEBUG_VM w konfiguracji jądra.

Inne podatności w Linux kernel

Zobacz wszystkie
Oryginalny opis (angielski, źródło NVD)

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.

Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS