Linux kernel BPF TCP iterator: double socket release on batch realloc failure panics the node

Impact

On a failed batch reallocation, bpf_iter_tcp_batch() returns early with cur_sk < end_sk over slots that now hold socket cookies rather than sock pointers; the stop callback then releases the batch a second time and dereferences a cookie as a struct sock. The reported effect is a KASAN null-pointer dereference and a fatal kernel panic - the record does not establish a controllable escalation. The operator cost is availability: a GPU node that panics takes every rank pinned to it with it, and in a collective training job that usually means the whole job restarts from the last checkpoint. Reaching it requires loading and reading a BPF TCP iterator, which is privileged work done by observability and socket-tracing agents, not by tenant pods.

Who can reach it

Local user able to create and read a bpf_iter TCP link - CAP_BPF/CAP_NET_ADMIN, effectively root or a privileged agent - combined with enough memory pressure to fail the batch reallocation.

What to do

Update to a stable kernel with the fix and reboot. In the meantime the exposure is bounded by which daemons load TCP iterators; auditing that set is cheaper than an unscheduled reboot. Batch this with your other pending kernel fixes - the drain cost on a GPU node is the same whether you take one fix or five.

References