CVE-2026-64541 in Linux
Summary
by MITRE • 07/28/2026
In the Linux kernel, the following vulnerability has been resolved:
net/smc: fix UAF in smc_cdc_rx_handler() by pinning the socket
smc_cdc_rx_handler() looks up the connection by token under the link group's conns_lock, drops the lock, and then dereferences conn and the smc_sock derived from it, ending in sock_hold(&smc->sk) inside smc_cdc_msg_recv(). No reference is held across the lock release.
The only reference pinning the socket while the connection is discoverable in the link group is taken in smc_lgr_register_conn() (sock_hold) and dropped in __smc_lgr_unregister_conn() (sock_put), both under conns_lock. Once the handler drops conns_lock, a concurrent close() -> smc_release() -> smc_conn_free() -> smc_lgr_unregister_conn() can drop that reference and free the smc_sock, so the handler's later sock_hold() runs on freed memory:
WARNING: lib/refcount.c:25 at refcount_warn_saturate Workqueue: rxe_wq do_work refcount_warn_saturate (lib/refcount.c:25) smc_cdc_msg_recv (net/smc/smc_cdc.c:430) smc_cdc_rx_handler (net/smc/smc_cdc.c:502) smc_wr_rx_tasklet_fn (net/smc/smc_wr.c:445) tasklet_action_common (kernel/softirq.c:938) handle_softirqs (kernel/softirq.c:622) Kernel panic - not syncing: panic_on_warn set
Only SMC-R is affected. The SMC-D receive tasklet is stopped by tasklet_kill(&conn->rx_tsklet) in smc_conn_free() before the connection is unregistered, so it cannot run concurrently with the free.
Take the socket reference while still holding conns_lock, so the registration reference can no longer be the last one, and drop it once the handler is done.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 07/28/2026
The vulnerability described represents a use-after-free condition in the Linux kernel's Scalable Reliable Communications (SMC) implementation specifically affecting SMC-R connections. This flaw exists within the smc_cdc_rx_handler() function which processes incoming CDC (Connection Data Channel) messages. The issue stems from improper reference management during concurrent access patterns where the socket reference is not maintained consistently across lock boundaries.
The technical root cause involves a race condition occurring in the connection lookup and processing flow. When smc_cdc_rx_handler() performs connection lookups by token under the link group's conns_lock, it releases this lock before dereferencing the connection structure and deriving the associated smc_sock. The function then calls sock_hold(&smc->sk) inside smc_cdc_msg_recv(), but no reference is held across the lock release point. This creates a window where concurrent operations can invalidate the socket reference.
Industry standards such as CWE-416 and CWE-362 directly apply to this vulnerability, with CWE-416 covering use-after-free conditions and CWE-362 addressing race conditions through improper locking mechanisms. The ATT&CK framework's T1059.008 technique for execution through command injection is indirectly relevant as this vulnerability could enable privilege escalation or system compromise if exploited by malicious actors.
The operational impact of this vulnerability is significant within systems utilizing SMC-R networking, particularly in high-performance computing environments where SMC is actively employed. A malicious actor could potentially trigger a kernel panic through carefully crafted network traffic, leading to system instability and denial of service. The vulnerability specifically affects SMC-R implementations while SMC-D remains unaffected due to different tasklet management patterns that prevent concurrent execution during connection cleanup.
The mitigation strategy requires modifying the smc_cdc_rx_handler() function to maintain socket references while holding the conns_lock, ensuring that the registration reference cannot become the last reference before processing completes. This approach aligns with established kernel security practices for preventing use-after-free conditions in concurrent data structures and follows the principle of maintaining consistent reference counts across lock boundaries as recommended by kernel security guidelines.
The fix involves taking socket references during the lock-held phase when connections are discoverable in the link group, preventing the scenario where concurrent close operations can drop the final reference while the handler continues processing. This maintains proper reference semantics throughout the entire connection lifecycle and eliminates the race condition that leads to the kernel panic observed in the vulnerability report.
The vulnerability demonstrates a classic concurrency issue where improper lock management creates opportunities for memory safety violations in kernel space networking code, highlighting the importance of maintaining consistent reference counting patterns even when working with complex locking schemes. The implementation of proper reference pinning during critical sections ensures that socket resources remain valid throughout the processing pipeline while still allowing for proper cleanup when connections are terminated.
This security flaw underscores the complexity of maintaining memory safety in kernel networking subsystems where multiple execution paths can concurrently access shared data structures, requiring careful attention to reference counting, locking protocols, and resource lifecycle management to prevent exploitation opportunities.