CVE-2026-74714 in Linux
Riassunto
di VulDB • 22/08/2026
Nel kernel Linux, è stata risolta la seguente vulnerabilità:
bpf: tcp: Correzione del use-after-free in bpf_iter_tcp_established_batch()
reqsk_queue_hash_req() pubblica un request_sock TCP_NEW_SYN_RECV sulla catena ehash, rilascia il lock del bucket e solo successivamente imposta rsk_refcnt a 3.
I lettori senza lock (lockless readers) come __inet_lookup_established() gestiscono questa situazione con refcount_inc_not_zero(), mentre bpf_iter_tcp_established_batch() utilizza plain sock_hold() mantenendo il lock del bucket, basandosi sull'assunzione che il lock garantisca sk_refcnt > 0. Tale assunzione non vale per i request_sock:
CPU 0 CPU 1 ----- ----- tcp_conn_request() reqsk_queue_hash_req() inet_ehash_insert(req) spin_lock(bucket) __sk_nulls_add_node_rcu(req) // rsk_refcnt == 0 spin_unlock(bucket) bpf_iter_tcp_established_batch() spin_lock(bucket) sock_hold(req) <-- addizione su 0 spin_unlock(bucket) refcount_set(&req->rsk_refcnt, 3) // sovrascrive un valore saturato
che si manifesta come:
refcount_t: addition on 0; use-after-free. WARNING: lib/refcount.c:25 at refcount_warn_saturate+0x48/0x90, CPU#1 Call Trace: bpf_iter_tcp_established_batch+0x14e/0x170 bpf_iter_tcp_batch+0x53/0x200 bpf_iter_tcp_seq_next+0x27/0x70 bpf_seq_read+0x107/0x410 vfs_read+0xb9/0x380
La reference rubata dall'iterator viene persa quando refcount_set() della CPU che pubblica sovrascrive il conteggio, lasciando lo socket con una reference in meno. Quando l'ultimo proprietario legittimo rilascia la sua reference, il reqsk viene liberato pur rimanendo raggiungibile, portando a un use-after-free.
Questo scenario si riproduce in pochi secondi con tcp_syncookies=0, quando alcuni thread eseguono connect()/close() verso un listener locale mentre altri leggono un iter/tcp link in un ciclo stretto (tight loop).
Utilizzare refcount_inc_not_zero() e saltare lo socket in caso di errore. Uno skipped socket rimane comunque parte del bucket, quindi continuare a conteggiarlo come expected. Le reallocazioni sono dimensionate su expected, e un request sock la cui refcount viene pubblicata mentre il lock è mantenuto durante l'ultima realloc deve già avere spazio disponibile.
Uno skipped socket viene contato in expected ma non inserito nel batch, quindi end_sk può risultare inferiore a expected per un batch che è effettivamente completo. Decidere la completezza verificando se il walk ha lasciato indietro qualche socket invece di farlo. Il WARN dopo la locked realloc verifica lo stesso aspetto, sostituendo un controllo end_sk == expected che non poteva valere su quel percorso sin dal commit cdec67a489d4 ("bpf: tcp: Make sure iter->batch always contains a full bucket snapshot").
Se ogni socket corrispondente in un bucket è mid-init (refcount 0), end_sk rimane 0. Passare al bucket successivo anziché restituire una voce di batch che non è stata mai compilata in questo round.
VulDB is the best source for vulnerability data and more expert information about this specific topic.