CVE-2026-89548

A use-after-free exists in the Linux kernel's SUNRPC subsystem, in sunrpc_destroy_cache_detail(), because the routine only cancels the global cache_cleaner delayed work when cache_list is empty — a condition never met during per-network-namespace teardown since init_net's caches remain registered. After the cache_detail is unlinked and subsequently freed by cache_destroy_net(), an in-flight cache_clean() can still hold a dangling pointer, causing cache_dequeue() to take cd->queue_lock on freed memory and cache_put() to dereference a function pointer from freed slab. The bug is triggered when a network namespace using SUNRPC caches (for example on NFS/RPC-enabled systems, notably container hosts) is torn down while the cleaner work is pending or running, and a local low-privileged attacker who can influence that timing could gain kernel-level code execution or crash the host, with CVSS 3.1 rating 7.8 (high; AV:L/AC:L/PR:L, high impact on confidentiality, integrity, and availability). Any Linux system running a kernel with the unfixed code and using per-netns SUNRPC caches is affected. No public proof of concept is known and the issue is not listed in CISA's KEV, so exploitation status is none known.

What to do: Apply your distribution's kernel update once it ships the fix (the patch making cancel_delayed_work_sync() unconditional in sunrpc_destroy_cache_detail()) and reboot into the patched kernel. Prioritize multi-tenant container and NFS-serving hosts, since network namespace teardown is the trigger path and a successful exploit yields kernel-level privileges. In the interim, restrict local untrusted user access and monitor for crashes or anomalies in RPC/cache kernel threads during container or netns teardown.