CVE-2026-80984: net/smc: do not dereference an unset send buffer on the SMC-D teardown path
In the Linux kernel, the following vulnerability has been resolved:
net/smc: do not dereference an unset send buffer on the SMC-D teardown path
smcclosestreamwait() calls smctxpreparedsends() from inside its skwaitevent() condition, and skwaitevent() evaluates that condition once with the socket lock released. smcdbufdetach() clears conn->sndbufdesc from smcconnkill() under locksock(), so a link group terminating while a socket waits there leaves the helper dereferencing NULL, faulting out of close(). SIOCOUTQ reads the field by hand, and smcclosecancelwork() drops the lock across two cancelsync() calls.
Sample the pointer once in the helper, report nothing prepared while it is unset, and bound the ioctl the same way. The receive tasklet dereferences the field directly in smccdcmsgrecvaction(), not through this helper; 1/2 is what keeps it from running that late.
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Systems using Linux SMC-D connections are exposed when an SMC-D link group terminates while a socket is waiting in the close path. The issue involves teardown of the SMC-D send buffer.
What conditions trigger the failure?
The failure occurs when smc_close_stream_wait() evaluates its wait condition without the socket lock while concurrent teardown clears conn->sndbuf_desc. A subsequent access to that unset pointer can cause close() to fault.
How might an affected system present?
An affected system may fault while closing an SMC-D socket during link-group termination. The SIOCOUTQ ioctl is also relevant because it reads the same send-buffer field and required equivalent bounds checking.