CVE-2026-23450: net/smc: fix NULL dereference and UAF in smc_tcp_syn_recv_sock()

In the Linux kernel, the following vulnerability has been resolved:

net/smc: fix NULL dereference and UAF in smctcpsynrecvsock()

Syzkaller reported a panic in smctcpsynrecvsock() [1].

smctcpsynrecvsock() is called in the TCP receive path (softirq) via icskafops->synrecvsock on the clcsock (TCP listening socket). It reads skuserdata to get the smcsock pointer. However, when the SMC listen socket is being closed concurrently, smccloseactive() sets clcsock->skuserdata to NULL under skcallbacklock, and then the smcsock itself can be freed via sockput() in smcrelease().

This leads to two issues:

1) NULL pointer dereference: skuserdata is NULL when accessed. 2) Use-after-free: skuserdata is read as non-NULL, but the smcsock is freed before its fields (e.g., queuedsmchs, oriafops) are accessed.

The race window looks like this (the syzkaller crash [1] triggers via the SYN cookie path: tcpgetcookiesock() -> smctcpsynrecvsock(), but the normal tcpcheckreq() path has the same race):

CPU A (softirq) CPU B (process ctx)

tcpv4rcv() TCPNEWSYNRECV: sk = req->rsklistener sockhold(sk) / No lock on listener / smccloseactive(): writelockbh(cblock) skuserdata = NULL writeunlockbh(cblock) ... smcclcsockrelease() sockput(smc->sk) x2 -> smcsock freed! tcpcheckreq() smctcpsynrecvsock(): smc = userdata(sk) -> NULL or dangling smc->queuedsmchs -> crash!

Note that the clcsock and smcsock are two independent objects with separate refcounts. TCP stack holds a reference on the clcsock, which keeps it alive, but this does NOT prevent the smcsock from being freed.

Fix this by using RCU and refcountincnotzero() to safely access smcsock. Since smctcpsynrecvsock() is called in the TCP three-way handshake path, taking readlockbh on skcallbacklock is too heavy and would not survive a SYN flood attack. Using rcureadlock() is much more lightweight.

- Set SOCKRCUFREE on the SMC listen socket so that smcsock freeing is deferred until after the RCU grace period. This guarantees the memory is still valid when accessed inside rcureadlock(). - Use rcureadlock() to protect reading skuserdata. - Use refcountincnotzero(&smc->sk.skrefcnt) to pin the smcsock. If the refcount has already reached zero (close path completed), it returns false and we bail out safely.

Note: smchscongested() has a similar lockless read of skuserdata without rcureadlock(), but it only checks for NULL and accesses the global smchswq, never dereferencing any smcsock field, so it is not affected.

Reproducer was verified with mdelay injection and smcrun, the issue no longer occurs with this patch applied.

[1] https://syzkaller.appspot.com/bug?extid=827ae2bfb3a3529333e9