GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel SMC: dst entry can be freed under smc_clc_prfx_set during connect(), a local UAF

CVE-2025-40139Kernel, userspace & hypervisorcurated

Impact

smc_clc_prfx_set() runs during connect() on an AF_SMC socket while holding neither RCU nor RTNL, and dereferences sk_dst_get(sk)->dev, so the destination cache entry and its netdev can be freed while still in use. The upstream fix switches to __sk_dst_get() and dst_dev_rcu() under rcu_read_lock(). A use-after-free in the socket path is the standard route from unprivileged code in a container to kernel compromise on the host, which on a multi-tenant GPU node means one tenant reaching the driver, the other tenants' memory and the node itself. The honest exposure caveat: SMC-R is the RDMA sockets protocol and almost no GPU fleet actually uses it, so the risk here is the module being loadable and reachable rather than the feature being deployed. This record contains the fix commits only and no exploitability analysis.

Who can reach it

Local. Any user or container process that can create an AF_SMC socket and call connect() on it, on a kernel where the smc module is present and loadable. No authentication beyond running code on the node. Unreachable where the module is absent or blacklisted.

What to do

Move to a stable kernel carrying the fix - the record links it across five stable branches - which means draining and rebooting each node, or applying a vendor live patch if one is offered for your kernel. Where SMC is not in use, which is the normal case, blacklisting the smc module prevents it from autoloading and removes the surface without a maintenance window; do that first and schedule the reboot with your next kernel cycle.

References

Related entries

All Kernel, userspace & hypervisor entries

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.