HIGH Introduced in 4.18
smc PipeBuf UAF
CVE-2026-80982
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
KernelScan AI6.9MEDIUM
01Description
In the Linux kernel, the following vulnerability has been resolved: net/smc: fix use-after-free in smc_rx_pipe_buf_release() smc_rx_splice() hands RMB pages to a pipe and takes a socket reference per entry so the smc_sock stays alive until the reader finishes. The connection does not: a concurrent close runs smc_conn_free(), which releases the receive buffer back to the link group pool. smc_rx_pipe_buf_release() tests sk_state before taking the socket lock. The state can change between the test and the lock, and smc_rx_update_cons() then dereferences conn->rmb_desc and walks conn->lgr, which smc_conn_free() has already released. On the is_reg_err path smcr_buf_unuse() frees the descriptor outright, so this is a use-after-free. Take the socket lock first and test conn->freed instead. smc_conn_free() 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.
02KernelScan AI Analysis
Risk summary
A local user who can create and use SMC (Shared Memory Communications) sockets can trigger a use-after-free by racing a splice() read against a concurrent close of the same socket. The freed connection resources are then dereferenced, leading to kernel memory corruption that is likely exploitable for privilege escalation or a denial-of-service crash. Systems that do not run untrusted local code or lack SMC kernel support are not at risk.
Vulnerability analysis
When a local process calls splice() on an SMC socket, the kernel transfers receive-buffer pages into a pipe and holds a reference on the socket so it stays alive until the reader finishes. The connection underneath, however, is not similarly pinned: a concurrent close can tear down and free the connection's receive buffer and link-group structures while the pipe buffer release callback is still running. The original code checked the socket state before acquiring the socket lock, leaving a window in which the state could change and the resources could be freed between the check and the lock. The release callback would then dereference the already-freed buffer descriptor and link group, a use-after-free. The fix acquires the socket lock first and tests a flag that the connection teardown sets before releasing anything; because both paths now hold the socket lock, they are mutually exclusive — either the release runs with everything still valid, or it sees the flag and skips the update. Any local user who can create an AF_SMC socket and invoke splice() can reach this code path; no special privileges are needed, though the SMC module must be loaded and an SMC-capable connection must exist.
Lifecycle
03Fix Versions
| Branch | Introduced | Fixed in | Patch commit |
|---|---|---|---|
| 6.18 | 4.18 | 6.18.50 | 0761e49aa78c |
| 6.1 | 4.18 | 6.1.188 | dadd97c8296b |
| 6.6 | 4.18 | 6.6.157 | df441f3efbb5 |
| 6.12 | 4.18 | 6.12.109 | 6a644a7340df |
| 7.2 | 4.18 | 7.2.4 | 0926f59ca0f9 |
| mainline | 4.18 | 7.3-rc1 | c924884743e9 |
| cip/6.12 | 4.18 | 6.12.111-cip32 | 6a644a7340df |