CVE-2026-74692 in Linux
Summary
by MITRE • 08/22/2026
In the Linux kernel, the following vulnerability has been resolved:
net/smc: fix TOCTOU race between smc_listen_out() and listener close
smc_listen_out() reads lsmc->sk.sk_state without the listener lock, then acquires lock_sock_nested() only after the check passes. This opens a window where smc_close_active() can transition the listener to SMC_CLOSED, call smc_close_cleanup_listen() to drain the accept queue, and release the lock, all between the lockless read and the delayed lock acquisition:
smc_listen_work (smc_hs_wq) smc_close_active() ------------------------------- ------------------------- release_sock(child) if (sk_state == SMC_LISTEN) TRUE lock_sock(listener) sk_state = SMC_CLOSED smc_close_cleanup_listen() release_sock(listener) flush_work(tcp_listen_work) lock_sock_nested(listener) smc_accept_enqueue(listener, child) /* child enqueued on dead listener */
smc_close_active() flushes only tcp_listen_work. Work items already dispatched onto smc_hs_wq for the CLC handshake continue running unguarded. smc_accept_enqueue() takes a sock_hold() on the child that is never released, so the child smc_sock, its clcsock, and the reference all leak. A remote peer that opens TCP connections while the server calls close() can exhaust kernel memory.
Move lock_sock_nested() to before the sk_state check so that the test and the enqueue are atomic under the listener lock.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/22/2026
The Linux kernel networking subsystem contains a time-of-check-to-time-of-use race condition within the SMC (Shared Memory Communications) implementation, specifically involving the interaction between smc_listen_out() and the listener close operation. This vulnerability arises from an improper locking sequence where the code reads the socket state variable lsmc->sk.sk_state without holding the associated listener lock. The acquisition of the lock via lock_sock_nested() occurs only after this initial check has been performed, creating a critical window during which concurrent operations can modify the underlying data structures in ways that invalidate the earlier assumption about the socket's status. This design flaw allows for a scenario where the state appears valid at the moment of inspection but becomes invalid by the time the lock is acquired and subsequent actions are taken based on that stale information.
The operational impact of this race condition manifests when smc_close_active() executes concurrently with the listening process. During this window, the close function can transition the listener socket to an SMC_CLOSED state and invoke smc_close_cleanup_listen(), which drains the accept queue and releases the lock. If a new connection attempt arrives during this interval, it may pass the initial state check because the socket was still in LISTEN mode at that precise moment. However, by the time the code attempts to enqueue the accepted child socket using smc_accept_enqueue(), the listener has already been closed and its resources cleaned up. This results in enqueuing a connection object onto a dead or invalid listener structure, leading to undefined behavior within the kernel's networking stack.
A significant consequence of this flaw is resource exhaustion due to reference counting errors. When smc_accept_enqueue() is called on an invalidated listener context, it performs a sock_hold() operation on the child socket but fails to release this reference later because the normal cleanup paths are bypassed or corrupted by the race condition. Consequently, the child SMC socket, its associated CLC socket, and all related references remain allocated in kernel memory indefinitely. This leads to a progressive leak of kernel resources that can be exploited remotely. An attacker who opens multiple TCP connections while triggering close operations on the server side can systematically exhaust available kernel memory, resulting in a denial of service condition for the entire system or specific network services hosted upon it.
From a classification perspective, this vulnerability aligns with CWE-367, which defines time-of-check-time-of-use (TOCTOU) race conditions where software performs a check on an object and then uses that object without ensuring that the object has not changed in between. In terms of adversarial tactics, this scenario relates to ATT&CK technique T1498, Network Denial of Service, specifically through resource exhaustion via kernel memory leaks rather than direct traffic flooding. The vulnerability highlights the importance of atomicity in state checks and subsequent actions within concurrent systems, particularly when dealing with network sockets that have complex lifecycle management requirements involving multiple reference counts and queue operations.
To mitigate this issue, the locking strategy must be adjusted to ensure that the check for the socket's listening state is performed atomically with the enqueue operation. The recommended fix involves moving the lock_sock_nested() call to precede the sk_state verification. By acquiring the listener lock before checking whether the socket is in a LISTEN state, the code ensures that no other thread can transition the socket to SMC_CLOSED or drain the accept queue during this critical section. This synchronization guarantees that if the state check passes, the subsequent enqueue operation will occur on a valid and active listener structure, preventing the enqueuing of connections onto closed listeners and eliminating the reference leak path. Maintaining strict lock ordering and minimizing the window between state checks and resource usage is essential for preserving kernel stability in high-concurrency network environments.