CVE-2026-89548

What it actually does

Use-after-free in SUNRPC cache teardown: sunrpc_destroy_cache_detail skips cancel_delayed_work_sync when cache_list is non-empty (as occurs during netns destruction), allowing cache_clean to dereference a freed cache_detail via queue_lock and cache_put function pointer.

Why it matters to the business

Local attackers on Linux systems can trigger kernel memory corruption, leading to crashes, denial of service, or potential privilege escalation; widespread impact due to presence in core networking stack across distributions.

How an attack unfolds

An attacker with local access triggers per-network-namespace teardown (e.g., via container shutdown or network namespace deletion), races the delayed cache_clean work against the freed cache_detail, and leverages the dangling pointers for arbitrary read/write or code execution within the kernel.

How to fix it

Apply the upstream fix that removes the list_empty guard around cancel_delayed_work_sync so the cleaner is always drained before cache_detail destruction; rebuild and deploy updated kernel packages containing this change.

How to confirm the fix worked

Confirm the patch is present by inspecting the sunrpc_destroy_cache_detail function for unconditional cancel_delayed_work_sync; test by exercising repeated netns creation/teardown under load and verify absence of slab UAF warnings in dmesg or kmemleak.

Typical attack path

1. Obtain local code execution on a Linux host
2. Create or destroy network namespaces to initiate per-netns SUNRPC cache teardown
3. Race the cache_clean delayed work against sunrpc_destroy_cache_detail freeing the object
4. Use resulting dangling pointers in cache_dequeue or cache_put for memory corruption
5. Escalate to kernel code execution or cause denial of service

How to detect it

Review kernel logs (dmesg, journalctl) for slab use-after-free warnings referencing cache_detail, queue_lock, or cache_put during network namespace teardown; correlate with container or netns lifecycle events in audit logs.

• cache_detail
• cache_clean
• sunrpc_destroy_cache_detail
• cache_dequeue

What your security team should do

• Prioritize kernel updates on all Linux systems exposed to untrusted local workloads or containers
• Monitor for kernel oops or slab corruption logs during namespace lifecycle events
• Restrict unprivileged namespace creation via kernel.unprivileged_userns_clone or similar controls until patched