GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel sunrpc: use-after-free when a network namespace is destroyed with an NFS TCP socket still armed

CVSS 7.8CVE-2024-53168Kernel, userspace & hypervisorcurated

Impact

A sunrpc kernel TCP socket can outlive the network namespace that allocated it, so the TCP write timer fires against freed memory and KASAN reports a use-after-free in tcp_write_timer_handler. The practical result is a kernel crash, and in principle freed-slab corruption, triggered from softirq context. This matters on GPU nodes because almost all of them mount NFS for datasets, checkpoints and home directories, and because containers create and tear down network namespaces constantly - the reproducer is an NFS mount inside a namespace whose FIN packets are dropped. A panic here takes the whole node down mid-job, which on a GPU host means losing every rank of a distributed training step, not just one workload.

Who can reach it

Local. Requires the ability to create network namespaces and drive NFS traffic inside them, which in practice means a privileged container or a user with CAP_NET_ADMIN and CAP_SYS_ADMIN in its own userns. Not reachable from the network by an unauthenticated attacker.

What to do

Take the stable kernel fix (five backport commits are listed, covering the affected stable branches) via your distribution kernel, then reboot each node to run it. There is no module reload or runtime mitigation for this path - sunrpc is in use as long as NFS is mounted - so schedule a rolling drain and reboot across the fleet. Nodes that mount NFS only in the host namespace and do not grant namespace creation to workloads are much harder to reach.

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.