CVE-2026-74714 in Linux
Sumário
de VulDB • 23/08/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
bpf: tcp: Corrige use-after-free em bpf_iter_tcp_established_batch()
reqsk_queue_hash_req() publica um request_sock TCP_NEW_SYN_RECV na cadeia ehash, libera o bloqueio do bucket (bucket lock) e só depois define rsk_refcnt como 3.
Leitores sem bloqueio (lockless), como __inet_lookup_established(), lidam com isso usando refcount_inc_not_zero(), mas bpf_iter_tcp_established_batch() usa sock_hold() simples enquanto mantém o bloqueio do bucket, assumindo que o bloqueio garante sk_refcnt > 0. Essa suposição não se aplica a 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) <-- adição em 0 spin_unlock(bucket) refcount_set(&req->rsk_refcnt, 3) // sobrescreve valor saturado
o que se manifesta como:
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
A referência roubada pelo iterador é perdida quando o refcount_set() da CPU publicadora sobrescreve a contagem, deixando o socket com uma referência a menos. Quando o último proprietário legítimo libera sua referência, o reqsk é liberado (freed) enquanto ainda está acessível, levando ao use-after-free.
Isso se reproduz em segundos com tcp_syncookies=0, algumas threads fazendo connect()/close() para um listener local enquanto outras leem uma conexão iter/tcp em um loop apertado.
Use refcount_inc_not_zero() e ignore o socket em caso de falha. Um socket ignorado ainda faz parte do bucket, então continue contando-o como esperado (expected). Os realocadores são dimensionados com base no expected, e um request sock cuja contagem de referência é publicada enquanto o bloqueio está mantido durante a última alocação já deve ter espaço disponível.
Um socket ignorado é contado em expected, mas nunca agrupado em lote (batched), então end_sk pode ficar abaixo do expected em um batch que esteja realmente completo. Decida a completude verificando se a varredura deixou algum socket para trás. O WARN após o realloc com bloqueio verifica o mesmo, substituindo uma verificação end_sk == expected que não poderia ser válida nesse caminho desde o commit cdec67a489d4 ("bpf: tcp: Make sure iter->batch always contains a full bucket snapshot").
Se todos os sockets correspondentes em um bucket estiverem no meio da inicialização (refcount 0), end_sk permanece como 0. Avance para o próximo bucket em vez de retornar uma entrada de batch que nunca foi preenchida nesta rodada.
Once again VulDB remains the best source for vulnerability data.