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 ]
Published: 2026-07-25
Score: 7.5 High
EPSS: < 1% Very Low
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

The vulnerability occurs in the Linux kernel’s svcrdma subsystem. When a transport is closed, threads parked in svc_rdma_sq_wait() on sc_sq_ticket_wait or sc_send_wait can become permanently stuck in a TASK_UNINTERRUPTIBLE state. During the close path the XPT_CLOSE flag is set but no explicit wake‑up is issued, so waiting threads never re‑evaluate their predicates. Consequently, these threads hold references to the transport, preventing svc_rdma_free() from completing and leading to a resource leak. The effect is a denial of service: affected kernel threads remain hung indefinitely, potentially exhausting system resources and preventing normal operation.

Affected Systems

This issue affects the Linux kernel on all versions that include the svcrdma implementation. No specific vendor or product version is listed; the problem exists as long as the affected code path is present in the kernel.

Risk and Exploitability

The CVSS score is 7.5, but the EPSS score is indicated as less than 1%, suggesting a very low probability of exploitation. The vulnerability is not listed in the CISA KEV catalog at present. Based on the description, the likely attack vector is remote, arising from a remote disconnect that triggers the problematic teardown path, though a local trigger could also trigger it by closing a connection from within the host. The exploit would involve causing a client to close the connection or disconnecting the RDMA transport, leading to kernel threads getting stuck and causing service disruption.

Generated by OpenCVE AI on August 13, 2026 at 17:59 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Apply the official kernel patch that introduces svc_rdma_xprt_deferred_close() and updates all producers to wake the appropriate wait queues
  • Upgrade to a kernel release where this fix is included (e.g., newer mainline or vendor‑specific patchset)
  • If the kernel cannot be immediately updated, monitor for hung svc_rdma threads and restart affected services or the machine to clear blocked state

Generated by OpenCVE AI on August 13, 2026 at 17:59 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Thu, 13 Aug 2026 16:00:00 +0000

Type Values Removed Values Added
Weaknesses NVD-CWE-noinfo

Wed, 29 Jul 2026 00:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-772
References
Metrics threat_severity

None

threat_severity

Moderate


Mon, 27 Jul 2026 05:15:00 +0000

Type Values Removed Values Added
Metrics cvssV3_1

{'score': 7.5, 'vector': 'CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H'}


Sat, 25 Jul 2026 09:30:00 +0000

Type Values Removed Values Added
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 ]
Title svcrdma: wake sq waiters when the transport closes
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-08-05T12:40:32.166Z

Reserved: 2026-07-19T15:36:31.777Z

Link: CVE-2026-64281

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Analyzed

Published: 2026-07-25T10:17:08.667

Modified: 2026-08-13T15:40:05.387

Link: CVE-2026-64281

cve-icon Redhat

Severity : Moderate

Publid Date: 2026-07-25T00:00:00Z

Links: CVE-2026-64281 - Bugzilla

cve-icon OpenCVE Enrichment

Updated: 2026-08-13T18:00:04Z

Weaknesses