CVE-2026-74714: bpf: tcp: Fix use-after-free in bpf_iter_tcp_established_batch()
bpf: tcp: Fix use-after-free in bpfitertcpestablishedbatch()
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 6.6.152.1-1
Event History
Frequently Asked Questions
What conditions are required to trigger the issue?
A TCP_NEW_SYN_RECV request_sock must be published on the TCP established hash chain while its rsk_refcnt is still zero, and bpf_iter_tcp_established_batch() must inspect it during that interval. The race occurs when the iterator calls sock_hold() under the bucket lock before reqsk_queue_hash_req() sets rsk_refcnt to 3.
How can administrators recognize that the race has occurred?
The kernel can report a refcount warning such as "refcount_t: addition on 0; use-after-free." The reported call trace includes bpf_iter_tcp_established_batch(), bpf_iter_tcp_batch(), bpf_iter_tcp_seq_next(), bpf_seq_read(), and may include vfs_read().
Which code behavior is unsafe in the affected path?
bpf_iter_tcp_established_batch() uses plain sock_hold() for entries found while holding the ehash bucket lock. For a newly published request_sock, the bucket lock does not guarantee that sk_refcnt is nonzero, because the reference count is initialized after the entry is published.