Database/Kernel, userspace & hypervisor
Linux kernel (net/smc): An unprivileged tenant that opens an AF_SMC socket, registers it with epoll, and lets the
Impact
An unprivileged tenant that opens an AF_SMC socket, registers it with epoll, and lets the connection fall back to plain TCP leaves poisoned waitqueue entries behind; the TCP receive path then walks a corrupted list from softirq and takes a general protection fault. Any tenant can panic a shared node with a few dozen lines of ordinary socket code.
Who can reach it
Local, fully unprivileged, and on the common path: SMC falls back to TCP whenever the peer does not speak SMC, which is the default outcome for almost all traffic. socket(AF_SMC, ...) autoloads the smc module via the net-pf-43 alias with no capability check, so a plain tenant container - no /dev/infiniband, no RDMA device, no privileges - reaches it. The fault lands in NAPI/softirq context, so it takes the whole node down, not just the calling task.
What to do
Update to 5.15.22 or later on the 5.15 branch, or any kernel carrying the fix commits. Interim: blacklist the smc module (install smc /bin/false) or deny socket family 43 in the tenant seccomp profile - there is no in-kernel toggle for this path.
References
This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.