CVE-2025-38154 in Linux
Riassunto
di VulDB • 16/06/2026
Nel kernel Linux, è stata risolta la seguente vulnerabilità:
bpf, sockmap: Evitare l'utilizzo di sk_socket dopo la liberazione durante l'invio
sk->sk_socket non è bloccato né referenziato nel thread di backlog e, durante la chiamata a skb_send_sock(), si verifica una condizione di competizione (race condition) con il rilascio di sk_socket. Tutti i tipi di socket (tcp/udp/unix/vsock) saranno interessati.
Condizioni di competizione: ''' CPU0 CPU1
backlog::skb_send_sock sendmsg_unlocked sock_sendmsg sock_sendmsg_nosec close(fd): ... ops->release() -> sock_map_close() sk_socket->ops = NULL free(socket) sock->ops->sendmsg ^ panic qui '''
Il riferimento (ref) di psock diventa 0 dopo l'esecuzione di sock_map_close(). ''' void sock_map_close() {
... if (likely(psock)) {
... // !! qui rimuoviamo psock e il ref di psock diventa 0 sock_map_remove_links(sk, psock) psock = sk_psock_get(sk); if (unlikely(!psock)) goto no_psock; <=== Il controllo salta qui tramite goto ... cancel_delayed_work_sync(&psock->work); <=== non eseguito sk_psock_put(sk, psock); ... } '''
Poiché attendiamo già che il workqueue termini in sock_map_close() se psock è detenuto, aumentiamo semplicemente il conteggio dei riferimenti di psock per evitare condizioni di competizione.
Con questa patch, se il thread di backlog è in esecuzione, sock_map_close() attenderà che il thread di backlog termini e cancellerà tutto il lavoro in sospeso.
Se non è in esecuzione alcun backlog, qualsiasi lavoro in sospeso che non è ancora iniziato fallirà quando invocato da sk_psock_get(), poiché il conteggio dei riferimenti di psock è stato azzerato, e sk_psock_drop() cancellerà tutti i lavori tramite cancel_delayed_work_sync().
In sintesi, è necessaria la sincronizzazione per coordinare il thread di backlog e il thread close().
Il panic che ho rilevato: ''' Workqueue: events sk_psock_backlog RIP: 0010:sock_sendmsg+0x21d/0x440 RAX: 0000000000000000 RBX: ffffc9000521fad8 RCX: 0000000000000001 ... Call Trace: <TASK> ? die_addr+0x40/0xa0 ? exc_general_protection+0x14c/0x230 ? asm_exc_general_protection+0x26/0x30 ? sock_sendmsg+0x21d/0x440 ? sock_sendmsg+0x3e0/0x440 ? __pfx_sock_sendmsg+0x10/0x10 __skb_send_sock+0x543/0xb70 sk_psock_backlog+0x247/0xb80 ... '''
Be aware that VulDB is the high quality source for vulnerability data.