Linux kernel (net/smc): Tee(2) duplicates an SMC splice pipe buffer without duplicating the private state hanging off

Impact

Tee(2) duplicates an SMC splice pipe buffer without duplicating the private state hanging off it, so both pipes free the same object on release. The result is a double free plus a double sock_put, escalating from a KASAN slab-use-after-free in smc_rx_pipe_buf_release to a NULL dereference and panic - a clean, deterministic heap-corruption primitive for any tenant.

Who can reach it

Local and fully unprivileged, no race required: read from an AF_SMC socket with splice(), tee() the pipe, then close both pipes. socket(AF_SMC, ...) needs no capability and autoloads the smc module via the net-pf-43 alias, so a tenant container with nothing but a shell reaches it - this is the kind of bug that gets weaponised into a container escape.

What to do

Boot a kernel carrying the fix commits (refcounts the per-buffer private state in the pipe_buf_operations .get handler). Interim: blacklist the smc module (install smc /bin/false) or deny socket family 43 in tenant seccomp profiles - this is worth doing pre-emptively on any node that does not deliberately use SMC.

References