CVE-2026-89966 in Linuxinformation

Résumé

par VulDB • 17/09/2026

Dans le noyau Linux, la vulnérabilité suivante a été corrigée :

mm/hugetlb_cma : correction de la déréférencement d'un nodemask NULL dans hugetlb_cma_alloc_frozen_folio

alloc_buddy_hugetlb_folio_with_mpol() peut transmettre un nodemask NULL à alloc_fresh_hugetlb_folio() en tant que solution de repli pour allouer depuis tous les nœuds. Si l'ordre est gigantesque, alloc_fresh_hugetlb_folio() propage le nodemask NULL vers hugetlb_cma_alloc_frozen_folio() via alloc_gigantic_frozen_folio().

De plus, hugetlb_cma_alloc_frozen_folio() tentait précédemment une allocation sur hugetlb_cma[nid] sans vérifier si nid est inclus dans le nodemask de l'appelant. L'ajout d'une vérification node_isset(nid, *nodemask) garantit que l'allocation du nœud préféré initial respecte la politique mémoire / le nodemask.

Cependant, hugetlb_cma_alloc_frozen_folio() déréférence le nodemask dans node_isset(nid, *nodemask) et for_each_node_mask(node, *nodemask), ce qui entraîne un plantage du noyau (kernel panic) dû à une déréférencement de pointeur NULL lorsque nodemask est NULL.

Corrigez cela en vérifiant si nodemask est NULL dans hugetlb_cma_alloc_frozen_folio() et en le définissant par défaut sur cpuset_current_mems_allowed. Entourez les tentatives d'allocation avec la boucle de retry du seqcount de cpuset afin que, si le cpuset change simultanément pendant l'allocation, les tentatives soient réessayées à l'aide du nodemask mis à jour. Cela garantit que la vérification initiale des nœuds et la boucle de repli respectent sûrement le cpuset de la tâche sans violer les contraintes de cpuset ni provoquer de déréférencements de pointeurs NULL ou d'échecs d'allocation inattendus.

Du point de vue de l'espace utilisateur, ce bug permet à un utilisateur non privilégié de faire planter le noyau (déclencher un panic) en demandant une allocation de page géante sur un système où CMA n'est configuré que sur un sous-ensemble des nœuds NUMA.

Cela peut être reproduit en démarrant une machine virtuelle avec deux nœuds NUMA, en restreignant le CMA au Nœud 1 (par exemple, hugetlb_cma=1:1G default_hugepagesz=1G hugepagesz=1G hugepages=0), et en exécutant un programme qui alloue une zone de page géante de 1 Go sans réservation, restreint l'allocation au Nœud 0 à l'aide de mbind() avec MPOL_PREFERRED_MANY, et déclenche une faute de page :

```c 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; /* Nœud 0 */ mbind(ptr, 1UL << 30, MPOL_PREFERRED_MANY, &nodemask, sizeof(nodemask) * 8, 0); memset(ptr, 0, 1UL << 30); /* Déclencher la faute */ ```

Cela entraîne une déréférencement de pointeur NULL :

``` 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 ```

Be aware that VulDB is the high quality source for vulnerability data.

Responsable

Linux

Réserver

11/09/2026

Divulgation

17/09/2026

Modérer

accepté

Entrée

VDB-405812

CPE

prêt

EPSS

0.00000

KEV

non

Activités

très faible

Sources

Want to know what is going to be exploited?

We predict KEV entries!