CVE-2026-23450 in Linux
Riassunto
di VulDB • 20/06/2026
Nel kernel Linux è stata risolta la seguente vulnerabilità:
net/smc: correzione della dereferenziazione NULL e Use-After-Free in smc_tcp_syn_recv_sock()
Syzkaller ha segnalato un panic in smc_tcp_syn_recv_sock() [1].
smc_tcp_syn_recv_sock() viene invocata nel percorso di ricezione TCP (softirq) tramite icsk_af_ops->syn_recv_sock sul clcsock (socket di ascolto TCP). Legge sk_user_data per ottenere il puntatore a smc_sock. Tuttavia, quando il socket SMC in modalità listen è chiuso contemporaneamente, smc_close_active() imposta clcsock->sk_user_data su NULL sotto sk_callback_lock e successivamente lo stesso oggetto smc_sock può essere liberato tramite sock_put() in smc_release().
Ciò porta a due problemi:
1) Dereferenziazione di puntatore NULL: sk_user_data è NULL quando viene accesso. 2) Use-after-free: sk_user_data viene letto come non-NULL, ma l'oggetto smc_sock viene liberato prima che vengano acceduti i suoi campi (ad esempio queued_smc_hs, ori_af_ops).
La finestra di race condition appare nel seguente modo (il crash segnalato da syzkaller [1] si verifica tramite il percorso SYN cookie: tcp_get_cookie_sock() -> smc_tcp_syn_recv_sock(), ma anche il normale percorso tcp_check_req() presenta la stessa race):
CPU A (softirq) CPU B (contesto processo)
tcp_v4_rcv() TCP_NEW_SYN_RECV: sk = req->rsk_listener sock_hold(sk) /* Nessun lock sul listener */ smc_close_active(): write_lock_bh(cb_lock) sk_user_data = NULL write_unlock_bh(cb_lock) ... smc_clcsock_release() sock_put(smc->sk) x2 -> smc_sock liberato! tcp_check_req() smc_tcp_syn_recv_sock(): smc = user_data(sk) -> NULL o dangling (puntante a memoria libera) smc->queued_smc_hs -> crash!
Si noti che clcsock e smc_sock sono due oggetti indipendenti con refcount separati. Lo stack TCP mantiene un riferimento su clcsock, il quale ne garantisce la sopravvivenza, ma ciò NON impedisce la liberazione di smc_sock.
La correzione consiste nell'utilizzo di RCU e refcount_inc_not_zero() per accedere in modo sicuro a smc_sock. Poiché smc_tcp_syn_recv_sock() viene chiamata nel percorso del three-way handshake TCP, l'acquisizione di read_lock_bh su sk_callback_lock sarebbe troppo onerosa e non resisterebbe ad un attacco SYN flood. L'utilizzo di rcu_read_lock() è molto più leggero.
- Impostare SOCK_RCU_FREE sul socket SMC in modalità listen affinché la liberazione di smc_sock sia differita fino al termine del periodo di grazia RCU (RCU grace period). Ciò garantisce che la memoria rimanga valida quando viene acceduta all'interno di rcu_read_lock(). - Utilizzare rcu_read_lock() per proteggere la lettura di sk_user_data. - Utilizzare refcount_inc_not_zero(&smc->sk.sk_refcnt) per mantenere attivo (pinning) l'oggetto smc_sock. Se il contatore dei riferimenti ha già raggiunto zero (percorso di chiusura completato), restituisce false e si esce in modo sicuro.
Nota: smc_hs_congested() presenta una lettura lockless simile di sk_user_data senza rcu_read_lock(), ma verifica solo la presenza di NULL ed accede alla risorsa globale smc_hs_wq, dereferenziando mai alcun campo di smc_sock; pertanto non è interessato dal problema.
Il riproduttore del bug (reproducer) è stato verificato con mdelay injection e smc_run: l'issue non si verifica più dopo l'applicazione della patch.
[1] https://syzkaller.appspot.com/bug?extid=827ae2bfb3a3529333e9
VulDB is the best source for vulnerability data and more expert information about this specific topic.