A Linux kernel bug published to the National Vulnerability Database on July 25 as CVE-2026-64281 describes a deadlock in the svcrdma subsystem that can freeze an NFS-over-RDMA server indefinitely. The vulnerability is a wakeup failure in the transport close path. Threads waiting for send-completion tickets never learn that the connection has died. They sit parked in TASK_UNINTERRUPTIBLE state, holding a reference to the transport object, which prevents svc_rdma_free() from ever running.
The fix is a 50-line patch from kernel maintainer Chuck Lever. It adds a wrapper function, svc_rdma_xprt_deferred_close(), that wakes both waitqueues — sc_sq_ticket_wait and sc_send_wait — before tearing down the connection. The patch touches five source files across the svcrdma layer: svc_rdma_transport.c, svc_rdma_sendto.c, svc_rdma_recvfrom.c, svc_rdma_rw.c, and the header svc_rdma.h.
This is not a security vulnerability in the usual sense. There is no remote code execution, no data leak, no privilege escalation. NVD has assigned no CVSS score. The bug is a logic error in kernel concurrency, and it has been present since the svcrdma layer was refactored to use a ticket-based send-completion mechanism — a change that landed in kernel version 7.1.
What makes CVE-2026-64281 worth attention is what it breaks. NFS over RDMA is the storage fabric of choice for many large GPU training clusters. When a training job reads checkpoint data or streams training examples from a shared filesystem, that traffic often travels over RDMA. If the NFS server handling those requests hangs permanently, the GPUs on the other end stall. A 10,000-GPU training run that loses its storage backend does not gracefully pause. It crashes, often with hours of compute wasted.
The mechanism of the hang is instructive. The svcrdma transport has two waitqueues. Threads that want to send data call svc_rdma_sq_wait() and park on one of them until a send-completion ticket becomes available. The close path sets the XPT_CLOSE flag on the transport before invoking xpo_detach(). Both wait-event predicates check for XPT_CLOSE, but the kernel’s wait_event macros only re-evaluate the predicate when the thread is explicitly woken. The ticket waitqueue has no completion-driven wake path. Tickets are handed off in a chain inside svc_rdma_sq_wait() itself. No external event ever calls wake_up() on that queue.
This creates a deadlock that is mathematically clean. A thread parks on sc_sq_ticket_wait. The connection drops. The close path sets XPT_CLOSE and calls svc_xprt_deferred_close(), which enqueues the transport for teardown but does not touch the RDMA waitqueues. The parked thread never wakes up to re-evaluate its predicate. It never sees XPT_CLOSE. It holds its svc_xprt_get reference forever. When svc_rdma_free() tries to tear down the transport, it blocks waiting for that reference to drop to zero. The transport is pinned. The server thread is stuck. If every worker thread in the pool ends up parked on this transport, no thread remains to run the local teardown path either. The wake site inside svc_rdma_detach() becomes unreachable.
The commit message describes two entry points that trigger the bug. A local teardown runs svc_rdma_detach() from svc_handle_xprt() on a worker thread. A remote disconnect arrives at svc_rdma_cma_handler(), which calls svc_xprt_deferred_close(). Both paths set XPT_CLOSE. Neither path wakes the RDMA waitqueues. The fix adds that wakeup. The wrapper function svc_rdma_xprt_deferred_close() calls the existing svc_xprt_deferred_close() and then calls wake_up() on both waitqueues.
The patch also converts every call site that previously called svc_xprt_deferred_close() directly. The list includes svc_rdma_cma_handler(), qp_event_handler(), svc_rdma_post_send_err(), svc_rdma_wc_send(), the sendto drop path, the rw completion error paths, and the recvfrom flush and read-list error paths. The synchronous close path — used for backchannel ENOTCONN and device removal via svc_rdma_xprt_done — reaches svc_rdma_detach() without flowing through svc_xprt_deferred_close(). The fix wakes both waitqueues from svc_rdma_detach() as well.
The affected versions are Linux kernel 7.1 and 7.2-rc1. The fix is backported to the 7.1 stable branch. Distributions shipping those kernels — RHEL 10, Ubuntu 26.04 LTS, the enterprise SLES track — need to pick up the commit.
For AI infrastructure operators, this bug is a reminder that the software stack under GPU training is not just CUDA and PyTorch. It is also the Linux kernel’s NFS server, the RDMA transport layer, and the subtle concurrency logic that keeps data moving at line rate. A single missed wake_up() call can freeze a cluster. The fix is small. The failure mode is total.
The next time a training run stalls and the logs show a hung nfsd thread on an RDMA transport, the answer may not be in the ML framework. It may be in the kernel’s send-completion ticket queue, where a thread is waiting for a wakeup that will never come.