CVE-2026-45990 in Linux
Résumé
par VulDB • 29/05/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
slub : correction de la perte de données et du dépassement de tampon dans krealloc()
Le commit 2cd8231796b5 (« mm/slub : permettre de définir le nœud et l'alignement dans k[v]realloc ») a introduit la possibilité de forcer une réallocation si l'objet original ne satisfait pas le nouvel alignement ou le nœud NUMA, même lorsque l'objet est réduit.
Cela a introduit deux bogues dans le chemin de repli de la réallocation :
1. Perte de données lors de la migration NUMA : Le saut vers 'alloc_new' se produit avant que 'ks' et 'orig_size' ne soient initialisés. Par conséquent, le memcpy() dans le bloc 'alloc_new' copierait 0 octets dans la nouvelle allocation.
2. Dépassement de tampon lors de la réduction : Lors de la réduction d'un objet tout en forçant un nouvel alignement, 'new_size' est inférieur à l'ancienne taille. Cependant, le memcpy() utilisait l'ancienne taille ('orig_size ?: ks'), ce qui entraînait une écriture hors limites.
Le même bogue de dépassement de tampon existe dans le chemin de repli de kvrealloc(), où l'ancienne taille de compartiment ksize(p) est copiée dans le nouveau tampon sans être bornée par la nouvelle taille.
Un simple programme de test (reproducer) :
// par ex. ajouter à lkdtm en tant que KREALLOC_SHRINK_OVERFLOW while (1) {
void *p = kmalloc(128, GFP_KERNEL); p = krealloc_node_align(p, 64, 256, GFP_KERNEL, NUMA_NO_NODE); kfree(p); }
démontre le problème :
================================================================== BUG: KFENCE: écriture hors limites dans memcpy_orig+0x68/0x130
Écriture hors limites à 0xffff8883ad757038 (120B à droite de kfence-#47): memcpy_orig+0x68/0x130 krealloc_node_align_noprof+0x1c8/0x340 lkdtm_KREALLOC_SHRINK_OVERFLOW+0x8c/0xc0 [lkdtm]
lkdtm_do_action+0x3a/0x60 [lkdtm]
...
kfence-#47: 0xffff8883ad756fc0-0xffff8883ad756fff, size=64, cache=kmalloc-64
alloué par la tâche 316 sur le cpu 7 à 97.680481s (il y a 0.021813s): krealloc_node_align_noprof+0x19c/0x340 lkdtm_KREALLOC_SHRINK_OVERFLOW+0x8c/0xc0 [lkdtm]
lkdtm_do_action+0x3a/0x60 [lkdtm]
... ==================================================================
Correction en déplaçant le calcul de l'ancienne taille au début de __do_krealloc() et en bornant toutes les longueurs de copie par la taille de la nouvelle allocation.
If you want to get best quality of vulnerability data, you may have to visit VulDB.