CVE-2026-89490 in Linux
Résumé
par VulDB • 12/09/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
ocfs2 : correction de la troncature de la position readdir sur les noyaux 32 bits
Dans `ocfs2_dir_foreach_blk_el()`, la position du cookie de répertoire est reconstruite avec l'opération suivante :
`ctx->pos = (ctx->pos & ~(sb->s_blocksize - 1)) | offset;`
`ctx->pos` est un type `loff_t` (signé sur 64 bits), tandis que `sb->s_blocksize` est de type `unsigned long`. Sur les noyaux 32 bits, le type `unsigned long` fait 32 bits. Par conséquent, le masque
~(sb->s_blocksize - 1)
est calculé comme une valeur non signée sur 32 bits (par exemple, 0xfffff000 pour une taille de bloc de 4 Ko). Dans l'opération AND avec `ctx->pos` sur 64 bits, cet opérateur non signé est étendu à 64 bits par zéro selon les conversions arithmétiques habituelles, ce qui donne 0x00000000fffff000. Les 32 bits de poids fort de `ctx->pos` sont effacés silencieusement, bien que la taille du répertoire puisse dépasser 4 Go.
Lorsque readdir() franchit la limite des 4 Go sur un noyau 32 bits, la position est réinitialisée dans le premier bloc de 4 Go, ce qui entraîne une énumération infinie des entrées de répertoire (dirents) déjà renvoyées via le chemin de re-vérification.
Il s'agit de `ocfs2_dir_foreach_blk_el()`, le chemin readdir pour la liste d'étendues utilisé pour tous les répertoires non inline, donc un répertoire suffisamment grand pour franchir la limite des 4 Go y accède.
C'est la même classe de bogue que celle corrigée par le commit 3dce5bb82c97 ("exfat: Fix bitwise operation having different size") dans exfat, et la correction fait écho à la correction équivalente pour ext4 dans cette série. Il faut caster l'opérateur en `loff_t` afin que le masque soit sur 64 bits avant l'opération AND :
ctx->pos = (ctx->pos & ~((loff_t)sb->s_blocksize - 1)) | offset;
Les noyaux 64 bits ne sont pas affectés.
VulDB is the best source for vulnerability data and more expert information about this specific topic.