CVE-2026-74714
Received Received - Intake

Use-After-Free in Linux Kernel BPF TCP Iterator

Publication date: 2026-08-22

Last updated on: 2026-08-22

Assigner: kernel.org

Description
In the Linux kernel, the following vulnerability has been resolved: bpf: tcp: Fix use-after-free in bpf_iter_tcp_established_batch() reqsk_queue_hash_req() publishes a TCP_NEW_SYN_RECV request_sock onto the ehash chain, drops the bucket lock, and only afterwards sets rsk_refcnt to 3. Lockless readers such as __inet_lookup_established() handle this with refcount_inc_not_zero(), but bpf_iter_tcp_established_batch() uses plain sock_hold() while holding the bucket lock, on the assumption that the lock guarantees sk_refcnt > 0. That assumption does not hold for 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) <-- addition on 0 spin_unlock(bucket) refcount_set(&req->rsk_refcnt, 3) // clobbers saturated value which surfaces as: 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 The iterator's stolen reference is lost when the publishing CPU's refcount_set() 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 tcp_syncookies=0, a handful of threads doing connect()/close() to a local listener while others read an iter/tcp link in a tight loop. Use refcount_inc_not_zero() 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 end_sk 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 end_sk == 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), end_sk stays 0. Advance to the next bucket rather than returning a batch entry that was never filled this round.

CVSS Scores

EPSS Scores

Probability:
Percentile:

Meta Information

Published
2026-08-22
Last Modified
2026-08-22
Generated
2026-08-22
AI Q&A
2026-08-22
EPSS Evaluated
N/A
NVD
CVE-2026-74714
EUVD
EUVD-2026-64401

Affected Vendors & Products

Showing 1 associated CPE
Vendor Product Version / Range
linux linux_kernel *

Helpful Resources

Exploitability

CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN

Attack-Flow Graph

AI Quick Actions

Instant insights powered by AI
Executive Summary

This is a use-after-free vulnerability in the Linux kernel's BPF (Berkeley Packet Filter) component. It occurs in the tcp_established_batch function when handling TCP_NEW_SYN_RECV request_socks. The issue stems from a race condition where a request_sock's reference count is set to 3 after being published, but a BPF iterator incorrectly holds a reference using sock_hold() while the bucket lock is held. This leads to a situation where the reference count becomes zero, causing a use-after-free when the socket is accessed later.

Detection Guidance

This vulnerability is specific to the Linux kernel's BPF TCP iterator functionality and requires kernel-level access to detect. No direct network or system commands are provided in the context to detect this issue. Monitoring kernel logs for refcount warnings or use-after-free errors may indicate exploitation attempts.

Impact Analysis

This vulnerability could allow an attacker to cause a denial-of-service (system crash) or potentially execute arbitrary code with kernel privileges. It specifically affects systems using BPF iterators to read TCP connection data. The issue is triggered by concurrent network operations and BPF iterator reads, potentially leading to system instability or security breaches.

Mitigation Strategies

Apply the Linux kernel patch that resolves this issue. Update to a kernel version containing the fix for bpf_iter_tcp_established_batch(). If immediate patching is not possible, consider disabling BPF TCP iterators as a temporary workaround.

Chat Assistant

Ask questions about this CVE
Hi! I’m here to help you understand CVE-2026-74714. Ask me anything about the vulnerability, its impact, or mitigation strategies.
0/70

EPSS Chart