CVE-2025-21683

What it actually does

Memory leak in Linux kernel BPF reuseport handling: bpf_sk_select_reuseport() can return an ESTABLISHED TCP socket that had SO_ATTACH_REUSEPORT_EBPF set, causing sk_reuseport_cb to exist without the expected refcount semantics; references are not dropped on both error paths after reuseport_alloc and related calls.

Why it matters to the business

Systems running custom BPF programs on socket reuseport may experience gradual kernel memory exhaustion, leading to degraded performance, increased latency, or eventual service disruption if the leak is triggered repeatedly.

How an attack unfolds

A local user crafts socket operations that attach a BPF program via SO_ATTACH_REUSEPORT_EBPF to a TCP socket, transitions it to ESTABLISHED state, then triggers error paths in sk_setsockopt or reuseport_attach_prog; each iteration leaks an unreferenced 2 KB object allocated via __kmalloc without ever being freed.

How to fix it

Upgrade the Linux kernel to a version containing commit bb36838dac7bb334a3f3d7eb29875593ec9473fc (or later stable equivalent) which adds the missing sk reference drops in both error paths of bpf_sk_select_reuseport().

How to confirm the fix worked

Confirm the running kernel contains commit bb36838dac7bb334a3f3d7eb29875593ec9473fc; re-run the reproducer from the commit message and verify no new unreferenced objects appear in kmemleak or slabinfo for __reuseport_alloc allocations.

Typical attack path

1. Create a TCP socket and attach a BPF program using SO_ATTACH_REUSEPORT_EBPF
2. Transition the socket to ESTABLISHED state while the reuseport callback remains attached
3. Invoke setsockopt paths that call sk_reuseport_attach_bpf and hit an error after reuseport_alloc
4. Repeat to accumulate unreferenced kernel objects and exhaust memory

How to detect it

Inspect kernel logs and kmemleak reports for unreferenced objects sized 2048 bytes allocated from __reuseport_alloc with backtraces containing reuseport_attach_prog, sk_reuseport_attach_bpf, and sk_setsockopt; correlate with processes calling setsockopt on reuseport sockets.

• unreferenced object 0xffff8881
• __reuseport_alloc+0x1d/0x40
• reuseport_attach_prog+0x87/0x140
• sk_reuseport_attach_bpf+0xc8/0x100

What your security team should do

• Apply the fixed kernel version immediately on any system exposing BPF socket programs to untrusted local users
• Monitor kernel memory usage and enable kmemleak on test systems to detect similar leaks
• Restrict unprivileged BPF and setsockopt capabilities via seccomp or LSM policies until patched