CVE-2026-68397 in Linux
Summary
by MITRE • 08/10/2026
In the Linux kernel, the following vulnerability has been resolved:
net/iucv: take a reference on the socket found in afiucv_hs_rcv()
afiucv_hs_rcv() looks up the destination socket under iucv_sk_list.lock, drops the lock, and then passes the socket to the afiucv_hs_callback_*() handlers without holding a reference. AF_IUCV sockets are not RCU-protected and are freed synchronously by iucv_sock_kill() -> sock_put(), so a concurrent close can free the socket in the window between read_unlock() and the handler, which then dereferences freed memory (for example sk->sk_data_ready() in afiucv_hs_callback_syn()).
Take a reference with sock_hold() while the socket is still on the list and release it with sock_put() once the handler has run.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 08/10/2026
The vulnerability resides within the Linux kernel's iucv networking subsystem where a race condition exists in the afiucv_hs_rcv() function that can lead to use-after-free conditions. This flaw occurs when the function performs socket lookup under the iucv_sk_list.lock mutex, subsequently releases the lock, and then passes the socket reference to callback handlers without maintaining an additional reference count. The iucv (Inter-User Communication Vector) protocol implementation does not utilize RCU (Read-Copy-Update) mechanisms for socket protection, making it susceptible to concurrent modification scenarios during socket lifecycle management.
The technical flaw manifests as a classic double-free or use-after-free vulnerability where the socket object can be freed by a concurrent close operation while the main execution path holds a reference to it but has already released the protecting lock. This creates a temporal window where afiucv_hs_callback_syn() and similar handlers attempt to dereference pointers to memory that has already been deallocated, specifically accessing sk->sk_data_ready() function pointer which becomes invalid upon socket destruction. The socket cleanup process occurs synchronously through iucv_sock_kill() which calls sock_put(), effectively destroying the socket object while other code paths may still hold references to it.
This vulnerability impacts the stability and security of systems utilizing IUCV networking, particularly in mainframe environments where this protocol is commonly deployed for inter-process communication. The operational impact includes potential system crashes, memory corruption, and denial-of-service conditions that can affect critical applications relying on IUCV connections. Attackers could potentially exploit this race condition to cause system instability or in more sophisticated scenarios, achieve privilege escalation by corrupting kernel memory structures.
The mitigation strategy requires implementing proper reference counting mechanisms by taking an additional reference with sock_hold() while the socket remains in the list structure and releasing it with sock_put() once all callback handlers have completed execution. This approach ensures that the socket object remains valid throughout the entire processing window, preventing concurrent access to freed memory structures. The fix aligns with established kernel security practices for handling shared data structures and follows principles outlined in CWE-415 and CWE-416 related to double-free conditions and use-after-free vulnerabilities.
This vulnerability demonstrates the importance of proper synchronization mechanisms in kernel space programming where multiple threads or processes may access shared resources concurrently. The solution addresses fundamental concurrency issues in socket management that are commonly addressed through reference counting patterns, similar to those recommended in the ATT&CK framework for kernel-level privilege escalation techniques. The fix ensures that all socket lifecycle operations maintain proper reference semantics while preserving the intended functionality of IUCV networking communication protocols.