DEBIAN-CVE-2026-23450

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