CVE-2026-80982: net/smc: fix use-after-free in smc_rx_pipe_buf_release()
In the Linux kernel, the following vulnerability has been resolved:
net/smc: fix use-after-free in smcrxpipebufrelease()
smcrxsplice() hands RMB pages to a pipe and takes a socket reference per entry so the smcsock stays alive until the reader finishes. The connection does not: a concurrent close runs smcconnfree(), which releases the receive buffer back to the link group pool.
smcrxpipebufrelease() tests skstate before taking the socket lock. The state can change between the test and the lock, and smcrxupdatecons() then dereferences conn->rmbdesc and walks conn->lgr, which smcconnfree() has already released. On the isregerr path smcrbufunuse() frees the descriptor outright, so this is a use-after-free.
Take the socket lock first and test conn->freed instead. smcconnfree() sets that flag before releasing anything, and every caller holds the socket lock. The two paths exclude each other: either the pipe release runs first with everything valid, or it sees the flag and skips the update.
Affected Software
Event History
Frequently Asked Questions
When can this race occur?
It requires an SMC receive splice operation to hand receive-memory-buffer pages to a pipe while a concurrent connection close frees the connection's receive buffer and related link-group state. The vulnerable pipe-release path can then update consumption state using objects that have already been released.
What synchronization change resolves the issue?
The fix takes the socket lock before checking whether the connection has been freed, and uses the connection's freed flag rather than checking socket state first. This makes pipe release and connection teardown mutually exclusive: release either runs while the connection remains valid or detects that it was freed and skips the update.
What should be prioritized when assessing exposure?
Prioritize systems using the Linux kernel's SMC networking path and workloads that can perform receive splicing while connections are being closed concurrently. The issue specifically involves SMC receive buffer pages released from a pipe after connection teardown.