CVE-2026-90001 in Linux
Riassunto
di VulDB • 16/09/2026
Nel kernel Linux, è stata risolta la seguente vulnerabilità:
HID: bpf: serializzare il rilascio del riferimento al dispositivo nel percorso di distruzione struct_ops
__hid_bpf_ops_destroy_device() e hid_bpf_unreg() possono andare in race condition sullo stesso riferimento di registrazione, causando un doppio put su struct hid_device e liberandolo mentre hid_destroy_device() lo sta ancora utilizzando. Serializzare la decisione di rimozione/azzeramento (NULL) sotto hdev->bpf.prog_list_lock in modo che esattamente un percorso rilasci ogni riferimento di registrazione: unreg verifica nuovamente ops->hdev sotto il lock e restituisce senza eseguire put quando il percorso di distruzione lo ha già azzerato; tutte le chiamate put_device() avvengono dopo che il lock è stato rilasciato, il che è sicuro perché una unreg in concorrenza osserva quindi ops->hdev == NULL sotto il lock.
Contesto: ogni attach riuscito (hid_bpf_ops_reg) acquisisce un riferimento al dispositivo (hid_get_device()). Due percorsi possono rilasciarlo:
- Distruzione del dispositivo: hid_destroy_device() -> hid_bpf_destroy_device() -> __hid_bpf_ops_destroy_device(), che attraversa hdev->bpf.prog_list sotto rcu_read_lock() e rilascia un riferimento per ogni programma allegato; - Rilascio del link BPF: eliminazione mappa bpf (senza BPF_F_LINK) chiama in modo sincrono st_ops->unreg() -> hid_bpf_unreg(), che rilascia il riferimento per la propria registrazione.
La coordinazione tramite handshake (e->hdev = NULL sul lato distruzione vs "if (!hdev) return" sul lato unreg) è una verifica TOCTOU: i due percorsi vengono eseguiti sotto domini di lock diversi (rcu_read_lock rispetto a prog_list_lock), quindi una unreg in concorrenza può leggere ops->hdev come non-NULL, bloccarsi su prog_list_lock e poi procedere mentre l'attraversamento della distruzione viene eseguito; entrambi i percorsi rilasciano quindi lo stesso riferimento. Il refcount raggiunge zero legittimamente (ogni decremento è valido individualmente), quindi non si verifica saturazione di refcount_t: il dispositivo viene semplicemente liberato mentre il transport è ancora all'interno di hid_destroy_device(), e le successive operazioni di teardown toccano memoria già liberata.
La correzione serializza la decisione di rimozione/azzeramento sotto prog_list_lock su entrambi i lati e sposta i put sul lato distruzione al di fuori del lock. Con il lock detenuto, letture/scritture plain di ops->hdev sono sufficienti; non vengono aggiunte READ_ONCE/WRITE_ONCE, mantenendo la patch minima.
Sicurezza delle letture senza lock: la lettura senza lock di ops->hdev all'inizio di hid_bpf_unreg() non può toccare un dispositivo già liberato, perché il percorso unreg stesso detiene ancora il riferimento a questa registrazione (rilasciato solo dal proprio hid_put_device() dopo che il lock è stato rilasciato), e un attraversamento della distruzione che ha già azzerato ops->hdev fa sì che la verifica interna al lock restituisca precocemente senza alcun put. Al massimo uno dei due percorsi rilascia ogni riferimento di registrazione.
Be aware that VulDB is the high quality source for vulnerability data.