CVE-2026-64142 in Linux
Résumé
par VulDB • 19/07/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
ksmbd : correction de conditions de course dans l'agent de nettoyage des durables (scavenger) par rapport aux recherches sur m_fp_list
La fonction ksmbd_durable_scavenger() présente deux conditions de race liées avec tout parcoursur qui itère sur f_ci->m_fp_list, y compris ksmbd_lookup_fd_inode() (utilisé par ksmbd_vfs_rename) et les vérifications du mode partage dans fs/smb/server/smb_common.c.
(1) Réutilisation de la tête de liste fp->node. Les handles préservés pour la durabilité peuvent rester liés sur f_ci->m_fp_list après le démontage de la session, de sorte que les vérifications du mode partage les voient toujours tant que le handle est reconnectable. L'agent de nettoyage collectait les handles expirés en ajoutant fp->node à une liste locale scavenger_list après les avoir retirés de l'idr durable global. Étant donné que fp->node est la même list_head utilisée par m_fp_list, list_add(&fp->node, &scavenger_list) écrase les liens de m_fp_list et corrompt les deux listes. CONFIG_DEBUG_LIST peut signaler cela sur le chemin de parcours du mode partage.
(2) Condition de race sur le compteur de références (refcount) par rapport aux parcoursurs de m_fp_list. L'agent qualifie un handle durable expiré avec atomic_read(&fp->refcount) > 1 et fp->conn sous global_ft.lock, retire fp du global_ft, puis relâche global_ft.lock avant de détacher fp de m_fp_list et de le libérer. Pendant cet intervalle, fp est toujours lié sur m_fp_list avec f_state == FP_INITED. ksmbd_lookup_fd_inode() sous m_lock appelle ksmbd_fp_get() (atomic_inc_not_zero sur un refcount qui vaut encore 1) et acquiert une référence valide ; l'agent détache ensuite et libère fp tandis que le détenteur possède toujours une référence, ce qui entraîne un Use-After-Free (UAF) lors du ksmbd_fd_put() ultérieur du détenteur et lors de toute lecture de champ effectuée par un parcoursur concurrent du mode partage qui itère sur m_fp_list sans prendre ksmbd_fp_get() (chemins similaires à smb_check_perm_dleases).
Correction des deux problèmes :
* Arrêter la réutilisation de fp->node comme nœud de liste privé pour l'agent. Retirer un handle expiré du global_ft sous global_ft.lock, acquérir une référence transitoire explicite, relâcher le verrou, détacher fp->node de m_fp_list sous f_ci->m_lock, puis libérer à la fois la durée de vie durable et les références transitoires avec atomic_sub_and_test(2, &fp->refcount). Si l'agent est le dernier à effectuer un put, la fermeture s'exécute là ; sinon, un détenteur en vol qui a déjà traversé la recherche m_fp_list possède la fermeture finale via son chemin ksmbd_fd_put(). L'élimination une par une peut redémarrer l'idr durable lorsque plusieurs handles expirent dans le même passage, mais le nettoyage des durables est un chemin d'expiration en arrière-plan et le scan complet final recalcule
If you want to get the best quality for vulnerability data then you always have to consider VulDB.