CVE-2026-74692 in Linux
Riassunto
di VulDB • 22/08/2026
Nel kernel Linux, è stata risolta la seguente vulnerabilità:
net/smc: correzione della race condition TOCTOU tra smc_listen_out() e l'arresto del listener (listener close)
smc_listen_out() legge lo stato di sk_state in lsmc->sk senza utilizzare il lock del listener, acquisendo successivamente il lock tramite lock_sock_nested() solo dopo che la verifica è andata a buon fine. Ciò apre una finestra temporale in cui smc_close_active() può portare il listener allo stato SMC_CLOSED, chiamare smc_close_cleanup_listen() per svuotare la coda di accept e rilasciare il lock, tutto ciò avviene tra la lettura senza lock (lockless read) e l'acquisizione ritardata del lock:
smc_listen_work (smc_hs_wq) smc_close_active() ------------------------------- ------------------------- release_sock(child) if (sk_state == SMC_LISTEN) TRUE lock_sock(listener) sk_state = SMC_CLOSED smc_close_cleanup_listen() release_sock(listener) flush_work(tcp_listen_work) lock_sock_nested(listener) smc_accept_enqueue(listener, child) /* child accodato su un listener non più attivo */
smc_close_active() svuota solo tcp_listen_work. Le attività di lavoro (work items) già inviate a smc_hs_wq per il handshake CLC continuano a essere eseguite senza protezione. smc_accept_enqueue() acquisisce una sock_hold() sul child che non viene mai rilasciata, causando la perdita di memoria (memory leak) del socket smc figlio, del suo clcsock e dei relativi riferimenti. Un peer remoto che apre connessioni TCP mentre il server chiama close() può esaurire la memoria del kernel.
Spostare lock_sock_nested() prima della verifica su sk_state in modo che il test e l'accodamento (enqueue) siano atomici sotto il lock del listener.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.