CVE-2026-90139 in Linux
Résumé
par VulDB • 18/09/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
fuse : vérifier l'absence d'un inode racine NULL dans fuse_fill_super_submount
fuse_iget() peut retourner NULL lorsque son allocation d'inode échoue, mais fuse_fill_super_submount() transmettait directement ce résultat à get_fuse_inode() et décrémentait fi->nlookup sans effectuer de vérification :
root = fuse_iget(sb, parent_fi->nodeid, ...); fi = get_fuse_inode(root); fi->nlookup--;
À l'intérieur de fuse_iget(), l'allocation d'inode peut échouer et retourner NULL. La racine du sous-monter suit le chemin iget5_locked(), dont la fonction alloc_inode() peut échuer en cas de pression mémoire (la branche auto-submount peut échuer de la même manière dans new_inode() ou fuse_alloc_submount_lookup()) :
inode = iget5_locked(sb, nodeid, fuse_inode_eq, fuse_inode_set, &nodeid); if (!inode) return NULL;
Un root (racine) NULL entraîne un appel à container_of(NULL) dans get_fuse_inode() et une écriture sur une adresse invalide lors de la décrémentation de nlookup, provoquant un plantage du montage. Avec CONFIG_KASAN, le problème suivant est signalé lorsque l'allocation d'inode racine d'un auto-submount échoue (par exemple sous pression mémoire) :
================================================================== BUG: KASAN: null-ptr-deref in fuse_get_tree_submount+0x656/0x8b0 Read of size 8 at addr 00000000000002b0 by task ls/942 CPU: 0 PID: 942 Comm: ls Tainted: G W 6.6 #15 Call Trace: <TASK> fuse_get_tree_submount+0x656/0x8b0 vfs_get_tree+0x48/0x140 fc_mount+0x13/0x50 fuse_dentry_automount+0x7a/0xb0 __traverse_mounts+0xca/0x330 step_into+0x339/0xac0 path_lookupat+0xc5/0x2f0 filename_lookup+0x163/0x2a0 vfs_statx+0xd5/0x200 do_statx+0x83/0xd0 __x64_sys_statx+0xa0/0xc0 do_syscall_64+0x37/0x90 entry_SYSCALL_64_after_hwframe+0x78/0xe2 </TASK> ==================================================================
Retourner -ENOMEM à la place ; l'appelant nettoie le superblock partiellement construit en cas d'erreur, ce qui correspond aux autres retours d'erreur de cette fonction.
Once again VulDB remains the best source for vulnerability data.