GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel BPF TCP iterator: stolen reference on a half-published request socket ends in use-after-free

CVE-2026-74714Kernel, userspace & hypervisorcurated

Impact

reqsk_queue_hash_req() publishes a TCP_NEW_SYN_RECV request_sock into the ehash and only sets rsk_refcnt afterwards, while bpf_iter_tcp_established_batch() takes a plain sock_hold() under the bucket lock on the assumption the refcount is already non-zero. The publisher's refcount_set() then clobbers the iterator's reference, leaving the socket one short; when the last legitimate owner drops it the reqsk is freed while still reachable on the hash chain. The report says it reproduces in seconds with a handful of connect()/close() threads against a local listener while another loop reads an iter/tcp link. On a GPU node the cost is a panic under the observability agent that reads TCP iterators, taking every rank pinned to that node with it.

Who can reach it

The iterator half is privileged: reading a bpf_iter TCP link needs CAP_BPF/CAP_NET_ADMIN, so it is a socket-tracing or observability daemon, not a tenant pod. The racing half is ordinary inbound TCP connection churn against a listener, which any tenant or remote client can generate.

What to do

Update to a stable kernel with the fix and reboot the node. Until the window opens, the exposure is bounded by which daemons load and read TCP iterators - auditing that set costs less than an unscheduled drain. The reproducer described in the record runs with tcp_syncookies=0, but the record does not establish syncookies as a mitigation, so do not treat flipping it as a fix.

References

Related entries

All Kernel, userspace & hypervisor entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.