CVE-2026-90001 in Linux
Résumé
par VulDB • 16/09/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
HID: bpf : sérialiser la libération de la référence d'appareil dans le chemin de destruction struct_ops
__hid_bpf_ops_destroy_device() et hid_bpf_unreg() peuvent entrer en concurrence (race condition) sur la même référence d'inscription, entraînant un double appel à put pour struct hid_device et sa libération alors que hid_destroy_device() l'utilise encore. Sérialisez la décision de suppression/définition à NULL sous hdev->bpf.prog_list_lock afin qu'un seul chemin libère chaque référence d'inscription : unreg vérifie à nouveau ops->hdev sous le verrou et retourne sans effectuer de put si le chemin de destruction l'a déjà effacé ; tous les appels put_device() ont lieu après la levée du verrou, ce qui est sûr car une déregistration concurrente observe alors ops->hdev == NULL sous le verrou.
Contexte : chaque attachement réussi (hid_bpf_ops_reg) acquiert une référence d'appareil (hid_get_device()). Deux chemins peuvent la libérer :
- Destruction de l'appareil : hid_destroy_device() -> hid_bpf_destroy_device() -> __hid_bpf_ops_destroy_device(), qui parcourt hdev->bpf.prog_list sous rcu_read_lock() et diminue d'une référence chaque programme attaché ; - Libération du lien BPF : suppression de la carte bpf (sans BPF_F_LINK) appelle synchrone st_ops->unreg() -> hid_bpf_unreg(), qui libère la référence pour sa propre inscription.
La poignée de coordination main gauche (e->hdev = NULL côté destruction vs "if (!hdev) return" côté unreg) est une vérification TOCTOU : les deux chemins s'exécutent sous différents domaines de verrouillage (rcu_read_lock vs prog_list_lock), donc une déregistration concurrente peut lire ops->hdev comme non-NULL, bloquer sur prog_list_lock, puis continuer tandis que le parcours de destruction s'exécute ; les deux chemins libèrent alors la même référence. Le compteur de références atteint zéro légitimement (chaque décrément est individuellement valide), donc aucune saturation refcount_t ne se produit : l'appareil est simplement libéré pendant que le transport est encore dans hid_destroy_device(), et les étapes ultérieures de démantèlement touchent une mémoire déjà libérée.
La correction sérialise la décision de suppression/définition à NULL sous prog_list_lock des deux côtés et déplace les puts côté destruction en dehors du verrou. Avec le verrou maintenu, des lectures/écritures simples de ops->hdev sont suffisantes ; aucun READ_ONCE/WRITE_ONCE n'est ajouté, maintenant ainsi un correctif minimal.
Sécurité de la lecture sans verrou : la lecture non protégée par verrou de ops->hdev au début de hid_bpf_unreg() ne peut pas toucher à un appareil libéré, car le chemin de déregistration détient toujours la référence d'inscription (libérée uniquement par son propre hid_put_device() après la levée du verrou), et un parcours de destruction qui a déjà effacé ops->hdev fait que la re-vérification sous le verrou retourne prématurément sans aucun put. Au plus, l'un des deux chemins libère chaque référence d'inscription.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.