UBUNTU-CVE-2026-74714: Use After Free
In the Linux kernel, the following vulnerability has been resolved: bpf: tcp: Fix use-after-free in bpfitertcpestablishedbatch() reqskqueuehashreq() publishes a TCPNEWSYNRECV requestsock onto the ehash chain, drops the bucket lock, and only afterwards sets rskrefcnt to 3. Lockless readers such as inetlookupestablished() handle this with refcountincnotzero(), but bpfitertcpestablishedbatch() uses plain sockhold() while holding the bucket lock, on the assumption that the lock guarantees skrefcnt > 0. That assumption does not hold for requestsock: CPU 0 CPU 1 ----- ----- tcpconnrequest() reqskqueuehashreq() inetehashinsert(req) spinlock(bucket) sknullsaddnodercu(req) // rskrefcnt == 0 spinunlock(bucket) bpfitertcpestablishedbatch() spinlock(bucket) sockhold(req) <-- addition on 0 spinunlock(bucket) refcountset(&req->rskrefcnt, 3) // clobbers saturated value which surfaces as: refcountt: addition on 0; use-after-free. WARNING: lib/refcount.c:25 at refcountwarnsaturate+0x48/0x90, CPU#1 Call Trace: bpfitertcpestablishedbatch+0x14e/0x170 bpfitertcpbatch+0x53/0x200 bpfitertcpseqnext+0x27/0x70 bpfseqread+0x107/0x410 vfsread+0xb9/0x380 The iterator's stolen reference is lost when the publishing CPU's refcountset() overwrites the count, leaving the socket one reference short. When the last legitimate owner drops its reference the reqsk is freed while still reachable, leading to use-after-free. This reproduces in seconds with tcpsyncookies=0, a handful of threads doing connect()/close() to a local listener while others read an iter/tcp link in a tight loop. Use refcountincnotzero() and skip the socket on failure. A skipped socket is still part of the bucket, so keep counting it in expected. The reallocations are sized from expected, and a request sock whose refcount gets published while the lock is held across the last realloc must already have room. A skipped socket is counted in expected but never batched, so endsk can be short of expected on a batch that is actually complete. Decide completeness by whether the walk left any socket behind instead. The WARN after the locked realloc checks the same, replacing an endsk == expected check that could not hold on that path since commit cdec67a489d4 ("bpf: tcp: Make sure iter->batch always contains a full bucket snapshot"). If every matching socket in a bucket is mid-init (refcount 0), endsk stays 0. Advance to the next bucket rather than returning a batch entry that was never filled this round.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
ubuntu/linux-hwe-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42~24.04.1 - Upgrade
Upgrade
ubuntu/linux-nvidia-tegrato a version that resolves this vulnerability.Fixed in 6.8.0-1036.39 - Upgrade
Upgrade
ubuntu/linux-riscv-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1~24.04.1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 7.0.0-42.42 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 7.0.0-1016.17 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 7.0.0-1016.18 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oem-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 7.0.0-1015.16 - Upgrade
Upgrade
ubuntu/linux-riscvto a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1 - Compensating control
In bpf_iter_tcp_established_batch(), replace plain sock_hold() with refcount_inc_not_zero() and skip sockets when the increment fails; continue counting skipped sockets in expected, advance to the next bucket instead of returning an unfilled batch entry, and determine completeness by whether the walk left any socket behind.
Event History
Frequently Asked Questions
Which Ubuntu systems are in scope?
The affected software list includes Ubuntu linux, linux-realtime, linux-azure, linux-gcp, linux-azure-fde, linux-gke, linux-riscv, and linux-gkeop kernel packages.
What conditions are required to trigger the issue?
The race involves a TCP request_sock in the TCP_NEW_SYN_RECV state being published on the established-hash chain while bpf_iter_tcp_established_batch() concurrently iterates it. The iterator performs sock_hold() before the request socket reference count is initialized, leading to a refcount addition on zero and potential use-after-free.
How might an affected system indicate that this has occurred?
A kernel warning may report "refcount_t: addition on 0; use-after-free" from refcount_warn_saturate. The call trace can include bpf_iter_tcp_established_batch(), bpf_iter_tcp_batch(), bpf_iter_tcp_seq_next(), bpf_seq_read(), and vfs_read().