CVE-2026-68386 in Linux
Summary
by MITRE • 08/10/2026
In the Linux kernel, the following vulnerability has been resolved:
bpf, sockmap: Reject unhashed UDP sockets on sockmap update
UDP sockets get SOCK_RCU_FREE set when (auto-)bound. This means sk_is_refcounted(unbound) = true, while sk_is_refcounted(bound) = false.
Because sockmap accepts unbound UDP sockets, a BPF program can increment a socket's refcount via lookup. If the socket is subsequently bound, the transition from unbound to bound causes bpf_sk_release() to skip the decrement of the refcount, causing a memory leak.
unreferenced object 0xffff88810bc2eb40 (size 1984): comm "test_progs", pid 2451, jiffies 4295320596 hex dump (first 32 bytes): 7f 00 00 01 7f 00 00 01 d2 04 1b b7 04 d2 00 00 ................ 02 00 01 40 00 00 00 00 00 00 00 00 00 00 00 00 ...@............ backtrace (crc bdee079d): kmem_cache_alloc_noprof+0x557/0x660 sk_prot_alloc+0x69/0x240 sk_alloc+0x30/0x460 inet_create+0x2ce/0xf80 __sock_create+0x25b/0x5c0 __sys_socket+0x119/0x1d0 __x64_sys_socket+0x72/0xd0 do_syscall_64+0xa1/0x5f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e
Instead of special-casing for refcounted sockets, reject unhashed UDP sockets during sockmap updates, as there is no benefit to supporting those. This effectively reverts the commit under Fixes, with two exceptions:
1. sock_map_sk_state_allowed() maintains a fall-through `return true`. 2. In the spirit of commit b8b8315e39ff ("bpf, sockmap: Remove unhash handler for BPF sockmap usage"), the proto::unhash BPF handler is not reintroduced.
Historical note: this issue is related to commit 67312adc96b5 ("bpf: reject unhashed sockets in bpf_sk_assign").
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/10/2026
This vulnerability resides within the linux kernel's bpf sockmap implementation and represents a memory leak caused by improper handling of udp socket reference counting during sockmap updates. The flaw specifically affects how bound versus unbound udp sockets are managed when transitioning between states, creating an inconsistency in reference count management that leads to unreferenced objects remaining in memory. The vulnerability stems from the fact that udp sockets receive the SOCK_RCU_FREE flag upon binding, which changes their reference counting behavior from unbound (refcounted) to bound (non-refcounted), yet sockmap operations still permit updates on unbound sockets.
The technical mechanism involves a race condition between socket lookup operations and socket state transitions that occurs when bpf programs interact with sockmaps containing udp sockets. When an unbound udp socket is referenced through a sockmap lookup operation, its reference count is incremented by the bpf program. However, upon subsequent binding of the same socket, the transition from unbound to bound state triggers a specific code path in bpf_sk_release() that skips the decrement of the reference count, resulting in a memory leak where objects remain allocated but unreferenced. This creates a persistent memory consumption issue that could be exploited for resource exhaustion attacks.
The operational impact of this vulnerability extends beyond simple memory leaks as it represents a fundamental inconsistency in kernel socket management that could potentially lead to more serious system stability issues. The leaked objects appear to be 1984-byte structures representing socket data with specific memory patterns indicating they are udp socket structures, and the backtrace shows allocation occurring through standard kernel socket creation paths including sk_prot_alloc and inet_create. This vulnerability affects systems running linux kernels that implement bpf sockmap functionality, particularly those utilizing bpf programs that interact with udp sockets in sockmap contexts.
The fix addresses this issue by rejecting unhashed udp sockets during sockmap updates rather than attempting to special-case reference counting behavior. This approach effectively reverts problematic changes while maintaining the broader sockmap functionality and ensuring proper socket lifecycle management. The solution aligns with security best practices by preventing potentially malicious bpf programs from exploiting reference counting inconsistencies, and it maintains consistency with existing kernel socket management patterns. This vulnerability demonstrates how seemingly minor implementation details in kernel networking code can create significant security implications, particularly when dealing with reference counting mechanisms that are critical for memory management.
From a cybersecurity perspective, this vulnerability maps to CWE-401 (Improper Release of Memory Before Removal from Resource Pool) and represents a classic example of resource leak exploitation. The attack surface is primarily through bpf programs that can access sockmaps, making it relevant to ATT&CK technique T1547.006 (System Service Hijacking) and T1059.006 (Command and Scripting Interpreter: Python) when considering how malicious actors might craft bpf programs to trigger the vulnerability. The historical context shows this issue was related to previous attempts to handle unhashed sockets more gracefully, but those approaches introduced complexity that ultimately led to this memory management flaw. This fix reinforces the principle that simpler, more predictable approaches to resource management are generally safer than complex special-case handling that can introduce subtle bugs.
The mitigation strategy focuses on eliminating the problematic code path entirely rather than attempting to patch around it, which represents a more robust approach to security engineering. By rejecting unhashed udp sockets at sockmap update time, the kernel prevents the race condition that enables the memory leak while maintaining compatibility with legitimate use cases. This solution also aligns with broader kernel security principles of minimizing attack surface and ensuring predictable resource management behavior. The approach taken in this fix demonstrates the importance of considering all possible state transitions when implementing complex kernel subsystems, particularly those involving reference counting and concurrent access patterns that are common in networking code.
This vulnerability highlights the challenges inherent in maintaining memory safety in complex kernel subsystems where multiple components must coordinate their resource management behaviors. The interaction between bpf programs, socket management, and reference counting creates a particularly challenging environment for security analysis. The fix represents a defensive programming approach that prioritizes correctness over convenience, ensuring that sockmap operations maintain consistent behavior regardless of socket state transitions. This vulnerability serves as an important reminder of the critical need for thorough testing of edge cases in kernel code, especially when dealing with concurrent access patterns and complex resource management scenarios that can have cascading effects on system stability and security.