CVE-2023-54269

What it actually does

Double-free of the xprt_ctxt pointer in SUNRPC deferred RPC request handling when a request is deferred a second time, allowing use of an already-freed object and subsequent kernel oops or memory corruption.

Why it matters to the business

Kernel instability or crashes on Linux systems handling RPC traffic such as NFS servers or clients, leading to service outages and potential data corruption during high-load or error-recovery scenarios.

How an attack unfolds

An attacker triggers repeated RPC request deferral conditions (for example through network packet loss or server overload) to cause the same svc_deferred_req to be reused without clearing the xprt_ctxt pointer, resulting in a second free of the object and subsequent invalid reference when the request is processed again.

How to fix it

Upgrade Linux kernel to a fixed version such as 5.15.113 or apply commit 7851771789e87108a92697194105ef0c9307dc5e; rebuild and reboot affected systems; for distributions without backports, apply the one-line change that always clears rq_xprt_ctxt in svc_defer().

How to confirm the fix worked

Confirm the kernel source contains the svc_defer() change that clears rq_xprt_ctxt and asserts the pointer is stored only in svc_deferred_req; run regression tests exercising multiple deferrals on UDP and RDMA transports; verify no double-free warnings in kmemleak or KASAN after applying the patch.

Typical attack path

1. Send crafted or lossy RPC traffic that forces repeated deferral of the same request
2. Trigger second deferral path in svc_defer() without rq_xprt_ctxt being cleared
3. Cause xpo_release_xprt to free or reuse the ctxt while it remains referenced
4. Trigger revisit of the deferred request to dereference the now-invalid ctxt

How to detect it

Inspect kernel logs for oops or BUG messages referencing xprt_ctxt, svc_deferred_req, or double-free in SUNRPC paths; examine crash dumps for use-after-free in xpo_release_xprt or rq_xprt_ctxt; no external network IOCs are expected because exploitation requires specific internal timing.

What your security team should do

• Prioritize patching kernel packages on all exposed NFS/RPC servers within normal change windows
• Monitor vendor advisories for distribution-specific backports of commit 7851771789e87108a92697194105ef0c9307dc5e
• Enable kernel memory debugging (KASAN/kmemleak) on test systems to validate the fix
• Review RPC-related logs for repeated deferral patterns as an early indicator of the bug trigger