Linux hwe edge: In the Linux kernel, the following vulnerability has been resolved: svcrdma: wake sq waiters when the transport closes Threads parked in… (CVE-2026-64281)
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 ]
AI Analysis
Technical Summary
The Linux kernel svcrdma transport had a flaw where threads parked in svc_rdma_sq_wait() on sc_sq_ticket_wait or sc_send_wait could remain indefinitely in TASK_UNINTERRUPTIBLE state when the transport closed. This happened because the wait predicates were only re-evaluated on wakeup, and sc_sq_ticket_wait lacked an explicit wake path on close. As a result, threads held references preventing svc_rdma_free() from completing. The fix introduced svc_rdma_xprt_deferred_close(), which wraps svc_xprt_deferred_close() and explicitly wakes both waitqueues. This wrapper was used in all relevant close paths to ensure parked threads re-evaluate their wait conditions and exit properly, allowing resource cleanup to proceed.
Potential Impact
Affected threads can hang indefinitely in an uninterruptible state during transport teardown, causing resource references to remain held and blocking cleanup functions like svc_rdma_free(). This can lead to resource leaks and potential denial of service conditions on the affected transport. There is no indication of remote code execution or privilege escalation from this issue.
Mitigation Recommendations
Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. The described fix involves kernel code changes introducing svc_rdma_xprt_deferred_close() and modifying transport close paths to wake waiting threads. Users should monitor official Linux kernel advisories and update to fixed kernel versions once available.
Linux hwe edge: In the Linux kernel, the following vulnerability has been resolved: svcrdma: wake sq waiters when the transport closes Threads parked in… (CVE-2026-64281)
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 ]
CVSS v3.1
Score 7.5high
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
The Linux kernel svcrdma transport had a flaw where threads parked in svc_rdma_sq_wait() on sc_sq_ticket_wait or sc_send_wait could remain indefinitely in TASK_UNINTERRUPTIBLE state when the transport closed. This happened because the wait predicates were only re-evaluated on wakeup, and sc_sq_ticket_wait lacked an explicit wake path on close. As a result, threads held references preventing svc_rdma_free() from completing. The fix introduced svc_rdma_xprt_deferred_close(), which wraps svc_xprt_deferred_close() and explicitly wakes both waitqueues. This wrapper was used in all relevant close paths to ensure parked threads re-evaluate their wait conditions and exit properly, allowing resource cleanup to proceed.
Potential Impact
Affected threads can hang indefinitely in an uninterruptible state during transport teardown, causing resource references to remain held and blocking cleanup functions like svc_rdma_free(). This can lead to resource leaks and potential denial of service conditions on the affected transport. There is no indication of remote code execution or privilege escalation from this issue.
Mitigation Recommendations
Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. The described fix involves kernel code changes introducing svc_rdma_xprt_deferred_close() and modifying transport close paths to wake waiting threads. Users should monitor official Linux kernel advisories and update to fixed kernel versions once available.
Technical Details
- Gcve Source
- db.gcve.eu
- Osv Id
- GHSA-xxjx-gf9q-559x
- Osv Schema Version
- 1.4.0
- Aliases
- ["CVE-2026-64281"]
- Ecosystems
- []
- Database Specific Severity
- null
- Cvss Version
- null
Threat ID: 6a65420e9c2644c7f808604e
Added to database: 07/25/2026, 23:09:02 UTC
Last enriched: 07/25/2026, 23:38:04 UTC
Last updated: 09/07/2026, 10:52:10 UTC
Views: 30
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.