CVE-2026-64281 Details
Description
In the Linux kernel, the following vulnerability has been resolved: svcrdma: wake sq waiters when the transport closes 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 ]
A vulnerability in the Linux kernel's RDMA service can lead to a deadlock situation. Threads waiting in the RDMA send queue can become stuck in a non-interruptible state when the transport is being torn down. This issue prevents the proper release of transport references, causing a blockage in the cleanup process. The problem arises because the transport closure does not properly wake up waiting threads, leaving them to hold onto references indefinitely. As a result, the RDMA service cannot free up resources, leading to potential memory leaks and degraded performance.
The vulnerability has been addressed in a patch that introduces a new function to properly handle the closure of RDMA transports. This function not only closes the transport but also wakes up any threads waiting in the send queue, allowing for a proper teardown of the transport without leaving threads hanging. Instructions for applying the patch can be found in the Linux kernel's official repository.
Metrics
CVSS 4.0 Severity and Vector Strings:
No CVSS 4.0 data is available for this CVE.
CVSS 3.x Severity and Vector Strings:
No data available for CVSS Version 2.0 on this CVE.
No SSVC data is available for this CVE.
References to Advisories, Solutions, and Tools
By selecting these links, you will be leaving this site. These are references gathered from the official CVE record and are not endorsed by Volerion.
| URL | Source(s) | Tag(s) |
|---|---|---|
| https://git.kernel.org/stable/c/40eedc4253dbda0b29b7961200534dfcecb48ace | kernel.org | Patch |
| https://git.kernel.org/stable/c/e5248a7426030db1e126363f72afdb3b71339a5c | kernel.org | Patch |
Weakness Enumeration
| CWE-ID | CWE Name | Source |
|---|---|---|
| NVD-CWE-noinfo | Insufficient Information to Classify Weakness | [email protected] |
Affected Products
| Product | Versions |
|---|---|
| linux linux kernel | >= 7.1, < 7.1.4 |
CPE
Remediation
| |
Change History
4 change records found show changes
| Date | Action | Recorded By |
|---|---|---|
| Aug 17, 2026 | CVE Modified | kernel.org |
| Aug 13, 2026 | Initial Analysis | [email protected] |
| Jul 27, 2026 | CVE Modified | kernel.org |
| Jul 25, 2026 | New CVE Received | kernel.org |