smc PipeBuf UAF

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.