CVE-2026-68386

What it actually does

The flaw allows a BPF sockmap update to accept an unbound UDP socket whose refcount is not decremented after a subsequent bind operation, because the kernel skips the decrement when the socket transitions from SOCK_RCU_FREE to bound state, resulting in a permanent kernel memory leak of sk_buff and socket structures.

Why it matters to the business

Repeated triggering can exhaust kernel memory on affected Linux systems, causing performance degradation, application crashes, or full system unavailability; the low EPSS and absence from KEV indicate limited real-world exploitation pressure 76 days after publication.

How an attack unfolds

An attacker loads a BPF program that performs a sockmap update on a freshly created unbound UDP socket, then binds the socket via the normal socket API; the refcount imbalance leaves the socket object unreferenced and never freed, leaking memory each time the sequence is repeated.

How to fix it

Upgrade the Linux kernel to a version containing the fix that rejects unhashed UDP sockets during sockmap updates; rebuild and redeploy any custom BPF programs that previously relied on the rejected behavior; test sockmap-using workloads after the update.

How to confirm the fix worked

Confirm the kernel version contains commit 67312adc96b5 or the equivalent sockmap rejection logic; run the kernel selftest test_progs that exercise sockmap with UDP sockets and verify no unreferenced socket objects remain after bind operations; monitor /proc/meminfo or slabinfo for unexpected growth in sock and sk_buff slabs under sockmap load.

Typical attack path

1. Create an unbound UDP socket from user space
2. Use a BPF program to insert the socket into a sockmap
3. Bind the socket to an address or port
4. Repeat the sequence to accumulate leaked kernel objects
5. Monitor or trigger memory pressure to achieve denial of service

How to detect it

Search kernel logs and audit trails for repeated sockmap update operations on UDP sockets followed by bind syscalls; monitor for slab allocation backtraces matching sk_alloc and inet_create from processes that also perform bpf map updates; look for growing numbers of unreferenced socket objects in kmemleak reports or slabinfo.

What your security team should do

• Prioritize kernel updates on systems that load BPF sockmap programs handling UDP traffic
• Audit BPF programs and user-space code that insert sockets into sockmaps to ensure they only use bound sockets
• Add kernel memory and slab usage monitoring to detect anomalous growth
• Review any downstream container or distribution images that ship affected kernel versions