CVE-2026-72196 in Linux
Résumé
par VulDB • 15/08/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
fs/ntfs3 : limitation de l'index dp->page_lcns[] lors du bloc copy_lcns dans la phase d'analyse
Lors de la phase d'analyse de log_replay(), après que find_dp() retourne un DIR_PAGE_ENTRY valide pour le tuple (target_attr, target_vcn), le bloc copy_lcns parcourt lrh->lcns_follow entrées supplémentaires :
t16 = le16_to_cpu(lrh->lcns_follow); for (i = 0; i < t16; i++) {
size_t j = (size_t)(le64_to_cpu(lrh->target_vcn) - le64_to_cpu(dp->vcn)); dp->page_lcns[j + i] = lrh->page_lcns[i];
}
find_dp() valide uniquement que target_vcn se situe dans l'intervalle [dp->vcn, dp->vcn + dp->lcns_follow), c'est-à-dire que le PREMIER cluster est couvert. Le parcours des entrées supplémentaires n'est pas borné par rapport à dp->lcns_follow. Pour un LRH malformé où target_vcn = dp->vcn + dp->lcns_follow - 1 et lrh->lcns_follow > 1, les écritures avec i > 0 provoquent un débordement du tableau page_lcns[] alloué pour dp.
Ajout de la garde manquante j + lrh->lcns_follow <= dp->lcns_follow.
Reproduit sous UML+KASAN sur le noyau principal (mainline) 8d90b09e6741 en tant qu'écriture slab-out-of-bounds de taille 8 depuis log_replay+0x68d4 lors du chemin de montage.
Ceci est distinct du correctif de Pavitra Jha daté du 2026-05-02 (« fs/ntfs3: validate lcns_follow in log_replay conversion », <[email protected]>) qui traite le chemin de conversion memmove(&dp->vcn, ...) séparé pour la table des pages sales (dirty-page-table) version 0. Les deux correctifs sont complémentaires ; les deux doivent être intégrés.
[[email protected] : formatage du code avec clang-format et résolution des conflits]
If you want to get the best quality for vulnerability data then you always have to consider VulDB.