CVE-2026-64142 in Linux
Riassunto
di VulDB • 20/07/2026
Nel kernel Linux è stata risolta la seguente vulnerabilità:
ksmbd: risoluzione delle race condition del scavenger di durable con le ricerche su m_fp_list
ksmbd_durable_scavenger() presenta due race condition correlate rispetto a qualsiasi iteratore che scorre f_ci->m_fp_list, tra cui ksmbd_lookup_fd_inode() (utilizzato da ksmbd_vfs_rename) e i controlli del share-mode in fs/smb/server/smb_common.c.
(1) Riutilizzo dell'elemento list-head di fp->node. I handle durable preservati possono rimanere collegati su f_ci->m_fp_list dopo la teardown della sessione, quindi i controlli dello share-mode li vedono ancora mentre l'handle è riconnessionabile. Lo scavenger raccoglieva gli handle scaduti aggiungendo fp->node a una locale scavenger_list dopo averli rimossi dal globale durable idr. Poiché fp->node è lo stesso list_head utilizzato da m_fp_list, list_add(&fp->node, &scavenger_list) sovrascrive i collegamenti di m_fp_list e corrompe entrambe le liste. CONFIG_DEBUG_LIST può segnalare questo problema sul percorso di scorrimento dello share-mode.
(2) Race condition del refcount con gli iteratori di m_fp_list. Lo scavenger qualifica un handle durable scaduto verificando atomic_read(&fp->refcount) > 1 e fp->conn sotto global_ft.lock, rimuove fp da global_ft, quindi rilascia global_ft.lock prima di scollegare fp da m_fp_list e liberarlo. Durante questa finestra temporale fp è ancora collegato su m_fp_list con f_state == FP_INITED. ksmbd_lookup_fd_inode() sotto m_lock chiama read ksmbd_fp_get() (atomic_inc_not_zero sul refcount che è ancora 1) ed ottiene un riferimento attivo; lo scavenger quindi scollega e libera fp mentre il detentore possiede un riferimento, portando a un Use-After-Free (UAF) nel successivo ksmbd_fd_put() del detentore e in qualsiasi lettura di campo eseguita da uno scorrimento concorrente dello share-mode che itera m_fp_list senza prendere ksmbd_fp_get() (percorsi simili a smb_check_perm_dleases).
Correzione di entrambi i problemi:
* Smettere di riutilizzare fp->node come nodo list privato per lo scavenger. Rimuovere un handle scaduto da global_ft sotto global_ft.lock, acquisire un riferimento transitorio esplicito, rilasciare il lock, scollegare fp->node da m_fp_list sotto f_ci->m_lock, quindi rilasciare sia la durata del durable che i riferimenti transitori con atomic_sub_and_test(2, &fp->refcount). Se lo scavenger è l'ultimo a effettuare un put, viene eseguita la chiusura lì; altrimenti un detentore in volo che ha già corso attraverso la ricerca su m_fp_list possiede la chiusura finale tramite il suo percorso ksmbd_fd_put(). La smaltimento uno alla volta può riesaminare il durable idr quando più handle scadono nello stesso passaggio, ma lo scavenging del durable è un percorso di scadenza in background e l'ultima scansione completa ricalcola min_timeout prima della prossima attesa.
* Azzerare fp->persistent_id all'interno di __ksmbd_remove_durable_fd() subito dopo idr_remove(), così che una
If you want to get best quality of vulnerability data, you may have to visit VulDB.