In the Linux kernel, the following vulnerability has been resolved:
net/smc: fix UAF in smccdcrx_handler() by pinning the socket
smccdcrxhandler() looks up the connection by token under the link group's connslock, drops the lock, and then dereferences conn and the smcsock derived from it, ending in sockhold(&smc->sk) inside smccdcmsg_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 smclgrregisterconn() (sockhold) and dropped in __smclgrunregisterconn() (sockput), both under connslock. Once the handler drops connslock, a concurrent close() -> smcrelease() -> smcconnfree() -> smclgrunregisterconn() can drop that reference and free the smcsock, so the handler's later sockhold() runs on freed memory:
WARNING: lib/refcount.c:25 at refcountwarnsaturate Workqueue: rxewq dowork refcountwarnsaturate (lib/refcount.c:25) smccdcmsgrecv (net/smc/smccdc.c:430) smccdcrxhandler (net/smc/smccdc.c:502) smcwrrxtaskletfn (net/smc/smcwr.c:445) taskletactioncommon (kernel/softirq.c:938) handlesoftirqs (kernel/softirq.c:622) Kernel panic - not syncing: paniconwarn set
Only SMC-R is affected. The SMC-D receive tasklet is stopped by taskletkill(&conn->rxtsklet) in smcconnfree() 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.
{
"cna_assigner": "Linux",
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/64xxx/CVE-2026-64541.json"
}