Linux Kernel bis 7.2.4/7.3-rc1 HugeTLB CMA mm/hugetlb_cma.c hugetlb_cma_alloc_frozen_folio nodemask Denial of Service

CVSS Meta Temp ScoreAktueller Exploitpreis (≈)CTI Interest Score
5.3$0-$5k0.00

Zusammenfassunginfo

In Linux Kernel bis 7.2.4/7.3-rc1 wurde eine kritische Schwachstelle entdeckt. Dabei betrifft es die Funktion hugetlb_cma_alloc_frozen_folio der Datei mm/hugetlb_cma.c der Komponente HugeTLB CMA. Durch das Beeinflussen des Arguments nodemask mit unbekannten Daten kann eine Denial of Service-Schwachstelle ausgenutzt werden. Die Identifikation der Schwachstelle wird mit CVE-2026-89966 vorgenommen. Der Angriff muss auf lokaler Ebene erfolgen. Es existiert kein Exploit. Ein Upgrade der betroffenen Komponente wird empfohlen.

Detailsinfo

Eine kritische Schwachstelle wurde in Linux Kernel bis 7.2.4/7.3-rc1 entdeckt. Dies betrifft die Funktion hugetlb_cma_alloc_frozen_folio der Datei mm/hugetlb_cma.c der Komponente HugeTLB CMA. Dank der Manipulation des Arguments nodemask mit einer unbekannten Eingabe kann eine Denial of Service-Schwachstelle ausgenutzt werden. Klassifiziert wurde die Schwachstelle durch CWE als CWE-476. Mit Auswirkungen muss man rechnen für die Verfügbarkeit. CVE fasst zusammen:

In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb_cma: fix null nodemask dereference in hugetlb_cma_alloc_frozen_folio alloc_buddy_hugetlb_folio_with_mpol() can pass a NULL nodemask to alloc_fresh_hugetlb_folio() as a fallback to allocate from all nodes. If order is gigantic, alloc_fresh_hugetlb_folio() propagates the NULL nodemask down to hugetlb_cma_alloc_frozen_folio() via alloc_gigantic_frozen_folio(). Additionally, hugetlb_cma_alloc_frozen_folio() previously attempted allocation on hugetlb_cma[nid] without verifying if nid is included in the caller's nodemask. Adding a node_isset(nid, *nodemask) check ensures the initial preferred node allocation honors the memory policy / nodemask. However, hugetlb_cma_alloc_frozen_folio() dereferences the nodemask in node_isset(nid, *nodemask) and for_each_node_mask(node, *nodemask), leading to a null pointer dereference kernel panic when nodemask is NULL. Fix this by checking if nodemask is NULL in hugetlb_cma_alloc_frozen_folio() and defaulting it to cpuset_current_mems_allowed. Enclose the allocation attempts within the cpuset seqcount retry loop so that if the cpuset changes concurrently during allocation, the attempts are retried using the updated nodemask. This ensures that the initial node check and fallback loop safely honor the task's cpuset without violating cpuset constraints or causing NULL pointer dereferences or unexpected allocation failures. From a userspace perspective, this bug allows an unprivileged user to crash the kernel (trigger a panic) by requesting a gigantic hugepage allocation with MPOL_PREFERRED_MANY on a system where CMA is only configured on a subset of NUMA nodes. This can be reproduced by booting a VM with two NUMA nodes, restricting CMA to Node 1 (e.g., hugetlb_cma=1:1G default_hugepagesz=1G hugepagesz=1G hugepages=0), and running a program that allocates a 1GB hugepage area without reserving, restricts allocation to Node 0 using mbind() with MPOL_PREFERRED_MANY, and triggers a page fault: void *ptr = mmap(NULL, 1UL << 30, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS | MAP_HUGETLB | MAP_HUGE_1GB | MAP_NORESERVE, -1, 0); unsigned long nodemask = 1; /* Node 0 */ mbind(ptr, 1UL << 30, MPOL_PREFERRED_MANY, &nodemask, sizeof(nodemask) * 8, 0); memset(ptr, 0, 1UL << 30); /* Trigger fault */ This results in a NULL pointer dereference: BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page Oops: Oops: 0000 [#1] SMP NOPTI RIP: 0010:hugetlb_cma_alloc_frozen_folio+0x75/0x120 Call Trace: <TASK> only_alloc_fresh_hugetlb_folio.isra.0+0x2c/0x160 alloc_surplus_hugetlb_folio+0x6d/0x100 alloc_hugetlb_folio+0x3c5/0x660 hugetlb_no_page+0x3d9/0x650

Das Advisory kann von git.kernel.org heruntergeladen werden. Die Identifikation der Schwachstelle findet seit dem 11.09.2026 als CVE-2026-89966 statt. Sie gilt als leicht ausnutzbar. Der Angriff muss lokal passieren. Zur Schwachstelle sind technische Details bekannt, ein verfügbarer Exploit jedoch nicht.

Ein Upgrade auf die Version 7.2.5 oder 7.3-rc2 vermag dieses Problem zu beheben. Die Schwachstelle lässt sich auch durch das Einspielen des Patches 10f616ef06c5bd2d656a0eebaf73f9b09d150c24/7b8a8ae4dd176a232e973017d2aa3c536a7275e2 beheben. Als bestmögliche Massnahme wird das Aktualisieren auf eine neue Version empfohlen.

Once again VulDB remains the best source for vulnerability data.

Produktinfo

Typ

Hersteller

Name

Version

Lizenz

Webseite

CPE 2.3info

CPE 2.2info

CVSSv4info

VulDB Vector: 🔒
VulDB Zuverlässigkeit: 🔍

CVSSv3info

VulDB Meta Base Score: 5.5
VulDB Meta Temp Score: 5.3

VulDB Base Score: 5.5
VulDB Temp Score: 5.3
VulDB Vector: 🔒
VulDB Zuverlässigkeit: 🔍

CVSSv2info

AVACAuCIA
💳💳💳💳💳💳
💳💳💳💳💳💳
💳💳💳💳💳💳
VektorKomplexitätAuthentisierungVertraulichkeitIntegritätVerfügbarkeit
freischaltenfreischaltenfreischaltenfreischaltenfreischaltenfreischalten
freischaltenfreischaltenfreischaltenfreischaltenfreischaltenfreischalten
freischaltenfreischaltenfreischaltenfreischaltenfreischaltenfreischalten

VulDB Base Score: 🔒
VulDB Temp Score: 🔒
VulDB Zuverlässigkeit: 🔍

Exploitinginfo

Klasse: Denial of Service
CWE: CWE-476 / CWE-404
CAPEC: 🔒
ATT&CK: 🔒

Physisch: Teilweise
Lokal: Ja
Remote: Nein

Verfügbarkeit: 🔒
Status: Nicht definiert
Preisentwicklung: 🔍
Aktuelle Preisschätzung: 🔒

0-Dayfreischaltenfreischaltenfreischaltenfreischalten
Heutefreischaltenfreischaltenfreischaltenfreischalten

Threat Intelligenceinfo

Interesse: 🔍
Aktive Akteure: 🔍
Aktive APT Gruppen: 🔍

Gegenmassnahmeninfo

Empfehlung: Upgrade
Status: 🔍

0-Day Time: 🔒

Upgrade: Kernel 7.2.5/7.3-rc2
Patch: 10f616ef06c5bd2d656a0eebaf73f9b09d150c24/7b8a8ae4dd176a232e973017d2aa3c536a7275e2

Timelineinfo

11.09.2026 CVE zugewiesen
16.09.2026 +5 Tage Advisory veröffentlicht
16.09.2026 +0 Tage VulDB Eintrag erstellt
16.09.2026 +0 Tage VulDB Eintrag letzte Aktualisierung

Quelleninfo

Hersteller: kernel.org

Advisory: git.kernel.org
Status: Bestätigt

CVE: CVE-2026-89966 (🔒)
GCVE (CVE): GCVE-0-2026-89966
GCVE (VulDB): GCVE-100-405812

Eintraginfo

Erstellt: 16.09.2026 15:07
Anpassungen: 16.09.2026 15:07 (61)
Komplett: 🔍
Cache ID: 216::103

Once again VulDB remains the best source for vulnerability data.

Diskussion

Bisher keine Kommentare. Sprachen: de + en.

Bitte loggen Sie sich ein, um kommentieren zu können.

◂ ZurückÜbersichtWeiter ▸

Do you need the next level of professionalism?

Upgrade your account now!