GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux BPF: bpf_sock_destroy() reads sk_protocol out of bounds on timewait and request sockets

UnscoredCVE-2026-98384Kernel, userspace & hypervisorcurated

Impact

sk_protocol lives in struct sock, not struct sock_common, but bpf_sock_destroy() read it unconditionally. The TCP BPF iterator can hand it a timewait or request sock, which is neither, so the read runs past the end of the smaller object - a 2-byte KASAN slab-out-of-bounds, which panics a kernel built with panic_on_warn and otherwise is an out-of-bounds read whose value then steers the destroy path. The fix checks sk_protocol only on full socks and relies on tcp_abort() to handle TIME_WAIT and NEW_SYN_RECV. Reachable only through BPF socket-iterator tooling, so on a GPU fleet the exposed hosts are the ones running socket-level observability or connection-reaping agents.

Who can reach it

Local and privileged: needs the ability to load and read a TCP BPF iterator program that calls bpf_sock_destroy(), i.e. CAP_BPF/CAP_SYS_ADMIN in the host network namespace. Not reachable from an unprivileged tenant pod.

What to do

Update to a stable kernel containing the fix (commits linked in the record); drain and reboot each node. Low urgency unless you run socket-destroying BPF iterators on these hosts - in which case note that a node with panic_on_warn set will hard-panic rather than merely over-read.

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.