GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel SUNRPC: use-after-free when a network namespace tears down an RPC cache

UnscoredCVE-2026-89548Kernel, userspace & hypervisorcurated

Impact

sunrpc_destroy_cache_detail() only cancelled the global cache_cleaner delayed work when the cache list was empty, which never happens during per-netns teardown because init_net's caches stay registered. The cache_detail is then freed while cache_clean() may still hold a pointer to it, so cache_dequeue() takes a spinlock in freed slab memory and cache_put() calls a function pointer read out of freed memory. On a GPU node this is the NFS/RPC client and server path: any workflow that creates and destroys network namespaces with RPC caches in them (containers mounting NFS, per-tenant netns) can drive the race. A function pointer read from reclaimed slab is the kind of primitive that turns a crash into privilege escalation if an attacker can groom the allocator.

Who can reach it

Local. A user or workload able to create and tear down network namespaces that register RPC caches - which in practice includes container workloads on the node - can reach the racing teardown path. No remote reachability, no authentication beyond local execution on the node.

What to do

Take the stable kernel update carrying the fix (the list_empty guard is dropped so cancel_delayed_work_sync() always runs). No runtime mitigation is available inside the kernel, so each node must be drained and rebooted onto the patched kernel; for a GPU fleet that means an eviction and reload cycle per node. The four stable commits are linked in the record; the advisory gives no fixed release numbers.

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.