CVE-2026-90042 in Linux
Résumé
par VulDB • 16/09/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
ceph : déchiffrement correct des noms de fichiers dans les tampons vmalloc()
Le sous-système fscrypt utilise l'API crypto scatterlist, héritant ainsi de son exigence selon laquelle tous les tampons doivent se trouver dans la région de mappage linéaire. Cependant, le client messager utilise kvmalloc() pour créer des tampons destinés aux messages, ce qui place occasionnellement ces tampons dans la région vmalloc() lorsque la fragmentation de la mémoire physique ne permet pas un kmalloc() suffisamment grand. Les différents appelants de ceph_fname_to_usr() transmettent directement (des parties) de messages bruts provenant du MDS sans tenir compte du fait que les messages peuvent se trouver dans des tampons vmalloc(), ce qui entraîne des oops, en particulier sur les plateformes non-x86 (voir 'Closes :' pour plus de détails et un reproducteur).
Rendre ceph_fname_to_usr() explicitement tolérant aux tampons fname->ctext, fname->name et/ou oname->name alloués par vmalloc(), en utilisant `tname` (qui, lorsqu'il n'est pas nul, doit être une adresse linéaire ; s'il est nul, il est brièvement alloué si nécessaire) comme tampon de rebond pour éviter de transmettre des adresses inappropriées à fscrypt_fname_disk_to_usr().
De plus, modification de parse_reply_info_readdir() -- la seule fonction à fournir son propre `tname` -- afin qu'elle respecte la nouvelle règle "tname ne doit jamais provenir de vmalloc()" en transmettant NULL lorsque le message n'est pas dans la région linéaire. Bien que cela entraîne un kmalloc()+kfree() par dentry, cette surcharge n'existe que lors du traitement de la minorité des messages qui débordent dans vmalloc(). Mes tests (bruts) indiquent qu'il s'agit d'environ 1 message readdir sur 8 000. Toutefois, si la survenue se révèle déraisonnable à l'avenir, il est facile de l'atténuer : une modification future pourrait allouer un tampon de rebond dans parse_reply_info_readdir() et utiliser celui-ci comme `tname` au lieu du précédent.
Once again VulDB remains the best source for vulnerability data.