Look up another CVE · open CVE-2026-64281 in the interactive tracker
CVE-2026-64281
svcrdma: wake sq waiters when the transport closes
Published 2026-07-25 (3 months ago) by the Linux kernel CNA. Subsystem include/linux. Debian urgency: unimportant.
What to do, per Debian release
Debian's own status for CVE-2026-64281 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | not affected | 6.1.190-1 | Nothing to do. bookworm never shipped the vulnerable code. |
| Debian 13trixie | not affected | 6.12.113-1 | Nothing to do. trixie never shipped the vulnerable code. |
| Debian 14forky | fixed | 7.1.4-1 | Update the kernel and reboot. Fixed in 7.1.4-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.1.4-1 | Update the kernel and reboot. Fixed in 7.1.4-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
Threads parked in svc_rdma_sq_wait() on sc_sq_ticket_wait or sc_send_wait can hang indefinitely in TASK_UNINTERRUPTIBLE state across transport teardown, pinning svc_xprt references and blocking svc_rdma_free(). The close path sets XPT_CLOSE before invoking xpo_detach and both wait_event predicates include an XPT_CLOSE term, but the predicates are re-evaluated only on wakeup. sc_sq_ticket_wait has no completion-driven wake path; it is advanced solely by the chained ticket handoff inside svc_rdma_sq_wait() itself. Without an explicit wake at close, parked threads never observe XPT_CLOSE, hold their svc_xprt_get reference forever, and svc_rdma_free() blocks on xpt_ref dropping to zero. Two close entry points reach this transport. Local teardown runs svc_rdma_detach() from svc_handle_xprt() -> svc_delete_xprt() -> xpo_detach() on a worker thread. A remote disconnect arrives at svc_rdma_cma_handler(), which calls svc_xprt_deferred_close(): that sets XPT_CLOSE and enqueues the transport but does not access either RDMA waitqueue, so a worker already parked in svc_rdma_sq_wait() never re-evaluates its predicate. With every worker parked on this transport, no thread is available to run the local teardown either, and the wake site there is unreachable. Introduce svc_rdma_xprt_deferred_close(), a thin svcrdma wrapper that calls svc_xprt_deferred_close() and then wakes both sc_sq_ticket_wait and sc_send_wait. Convert the svcrdma producers that called svc_xprt_deferred_close() directly: 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. Wake both waitqueues from svc_rdma_detach() as well. The synchronous svc_xprt_close() path (backchannel ENOTCONN, device removal via svc_rdma_xprt_done) reaches detach without flowing through svc_xprt_deferred_close() and therefore does not invoke the new helper. [ cel: add svc_rdma_xprt_deferred_close() to complete the fix ]
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
include/linux/sunrpc/svc_rdma.h
net/sunrpc/xprtrdma/svc_rdma_recvfrom.c
net/sunrpc/xprtrdma/svc_rdma_rw.c
net/sunrpc/xprtrdma/svc_rdma_sendto.c
net/sunrpc/xprtrdma/svc_rdma_transport.c
- What this is
- KERNEL NFSD, SUNRPC, AND LOCKD SERVERSMAINTAINERS section matched on include/linux/sunrpc/ · linux-nfs@vger.kernel.org · Supported
- Kernel module
- rpcrdma
Check it on the machine
grep -wE 'CONFIG_SUNRPC|CONFIG_SUNRPC_XPRT_RDMA' /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
lsmod | grep -w rpcrdmaPrints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.
Show whether Debian builds this, per release
Debian builds this as a loadable module. Every release below compiles it as a module on every flavour, so whether the code is in the running kernel depends on whether that module is loaded.
- bookworm, trixie, forky, sidm
- m
- a loadable module on every flavour - check lsmod, can be blacklisted
- Build switches
- CONFIG_SUNRPC, CONFIG_SUNRPC_XPRT_RDMA
- Reads as
- all on means the file is compiled; any one off means it is not.
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-07-25 (3 months ago)source
- CVSS
- 7.5 high
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:Hsource recompute it - Attack vector
- network (AV:N)source
- EPSS
- 0.49%, higher than 40.6% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- unimportantsource
- Subsystem
- include/linux
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 7.1 | 7.1.4 | 40eedc4253db |
| 7.1 | 7.2 | e5248a742603 |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:NAttack vector, network
- An unauthenticated peer can reach the vulnerable NFS/RDMA server over an IP-based RDMA connection, including routable iWARP or RoCE deployments.
- AC:LAttack complexity, low
- The attacker controls concurrent request batching, Send Queue pressure, and the remote disconnect that strands waiters, and can repeat attempts without relying on an uncontrollable race.
- PR:NPrivileges required, none
- Malformed RPC/RDMA headers can reach svc_rdma_sq_wait() through the transport-error reply path before RPC authentication, NFS export authorization, or credential validation.
- UI:NUser interaction, none
- Exploitation requires only attacker-generated RDMA traffic and disconnection; no victim action is required after the service is listening.
- S:UScope, unchanged
- The vulnerable transport and affected NFS service threads belong to the same host kernel security authority.
- C:NConfidentiality impact, none
- The defect is a missed wake-up that pins references and does not disclose data or provide a memory-read primitive.
- I:NIntegrity impact, none
- No memory corruption, unintended write, or data modification occurs; retained references prevent premature object destruction.
- A:HAvailability impact, high
- Waiters remain indefinitely in TASK_UNINTERRUPTIBLE, and an attacker can park all NFS service workers and block transport teardown or server shutdown, causing complete service availability loss.