CVE-2026-89536

What it actually does

A race in the Linux kernel SUNRPC client TLS handshake can free the lower RPC transport while the completion callback still uses it. On timeout or signal, the waiter may drop a callback-owned reference after cancel loses to completion, causing a use-after-free of kernel xprt state. That can corrupt kernel memory, panic the host, or enable kernel-level code execution.

Why it matters to the business

Hosts that start NFS or other RPC-over-TLS client connections can crash (outage) or be fully taken over if the race is abused, with confidentiality, integrity, and availability all at risk. The issue is scored 9.8 (network, no privileges or user interaction). It is not in CISA KEV, is not tied to ransomware, and has no known public exploit 34 days after publication, but a kernel use-after-free still warrants urgent patching wherever RPC TLS clients run.

How an attack unfolds

A Linux RPC client holds a transport reference for the TLS handshake completion callback. An attacker who can be the RPC/TLS peer, or who can force handshake timeouts, completes the handshake at the same time the client cancels it. Cancel then reports the request already complete, so the waiter frees the lower transport while xs_tls_handshake_done() is still running. The callback touches freed kernel memory, which can panic the system or be abused for kernel code execution and full host control. No named threat actors or public exploits are associated with this CVE.

How to fix it

Install a Linux kernel that includes the SUNRPC fix to wait for the in-flight client TLS handshake callback before dropping the lower-transport reference on cancel or timeout. This record lists no package names or fixed versions; use the latest vendor kernel and confirm the changelog covers SUNRPC TLS handshake lifetime handling (wait for xs_tls_handshake_done). Until patched, avoid RPC-over-TLS to untrusted servers and disable TLS-wrapped RPC clients if they are not required. Patching is the only complete fix.

How to confirm the fix worked

Confirm the running kernel matches a vendor release whose notes mention the SUNRPC client TLS handshake callback lifetime fix, then retest NFS/RPC-over-TLS mounts and reconnects. Inventory remaining unpatched kernels that use xprt TLS/kTLS RPC clients. Absence of sunrpc TLS handshake oopses after upgrade supports that the race is closed.

Typical attack path

1. Cause the target to start a SUNRPC client TLS handshake (for example NFS/RPC reconnect to an attacker-influenced server).
2. Race handshake completion against client cancel via timeout or signal.
3. Trigger use-after-free of the lower transport while the completion callback still runs.
4. Turn kernel memory corruption into a panic or kernel-level code execution.
5. Operate from kernel/root context on the compromised host.

How to detect it

No in-the-wild campaigns or named actors are known. Hunt kernel logs and crash dumps, not user-space malware artifacts: dmesg, journalctl -k, /var/log/kern.log, and kdump/vmcore for oops/panic stacks through sunrpc TLS handshake code (xs_tls_handshake_done, xs_tls_handshake_sync, tls_handshake_cancel). Correlate with NFS/RPC TLS mount or reconnect activity and unexpected RPC peers. Missing oopses do not prove the race never fired if the host rebooted without persistent kernel logs.

• xs_tls_handshake_done
• xs_tls_handshake_sync
• tls_handshake_cancel
• handshake_req_cancel
• Call Trace:.*\bsunrpc\b

What your security team should do

• Patch kernels on any host that initiates NFS or other SUNRPC TLS client connections; treat this as critical despite no KEV listing and no known exploit 34 days after publication.
• Inventory RPC-over-TLS client usage and untrusted or Internet-reachable RPC peers.
• Until patched, restrict TLS RPC clients to trusted servers and watch for sunrpc/TLS handshake kernel oopses.
• After patching, verify kernel/package version and watch for recurrence of related panics.
• Track distribution kernel advisories and reassess if public exploit code appears.