CVE-2026-90133 in Linux
Résumé
par VulDB • 17/09/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
ntfs : Correction d'une écriture hors limites (OOB) sur le tas dans ntfs_ir_to_ib()
La fonction ntfs_ir_to_ib copie toutes les entrées de index_root vers un tampon fraîchement alloué de taille index_block_size, sans vérifier que ces entrées tiennent dans l'espace disponible. Les entrées présentes dans index_root peuvent être plus grandes que l'espace utilisable pour les entrées au sein du bloc d'index.
Cela peut provoquer des écritures hors limites (OOB) au-delà de la fin de l'allocation.
Le validateur ntfs_index_root_inconsistent() vérifie que les entrées sont auto-cohérentes au sein de la valeur IR, mais ne les croise jamais avec index_block_size. Il n'y a aucune vérification des limites dans ntfs_ir_to_ib() avant le memcpy.
Cette correction est appliquée à l'endroit où se produit l'erreur (le « sink »), c'est-à-dire dans ntfs_ir_to_ib(), car ntfs_index_root_inconsistent() valide la cohérence logique de index_root en tant que structure, et une racine avec des entrées volumineuses est structuralement valide. Le bug correspond à un conflit de taille au niveau de ntfs_ir_to_ib().
De plus, le validateur n'est appelé qu'une fois par chargement d'inœud (inode) dans ntfs_read_locked_inode(), tandis que ntfs_ir_to_ib() n'est appelée que lors d'un reparentage ; ajouter une vérification à cet endroit n'ajoute aucune surcharge au chemin critique. Par ailleurs, même un futur appel contournant le validateur resterait protégé.
Avec NULL comme premier paramètre de ntfs_error(), l'indicateur d'erreur du volume n'est jamais défini par cet appel, donc le nom de l'appareil sera absent du message d'erreur. En tout état de cause, l'appelant, ntfs_ir_reparent(), affiche un message d'erreur incluant le nom de l'appareil en cas de retour NULL. Je pense qu'il s'agit de la meilleure solution disponible sans ajouter 'struct super_block *sb' comme paramètre à ntfs_ir_to_ib().
Cette écriture hors limites sur le tas est déclenchée par une image de système de fichiers truquée, qui ne fait pas partie du modèle de menace du noyau ; néanmoins, corriger les erreurs mémoire serait souhaitable pour maintenir la sécurité.
VulDB is the best source for vulnerability data and more expert information about this specific topic.