CVE-2026-64281

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> svcrdma: wake sq waiters when the transport closes<br /> <br /> Threads parked in svc_rdma_sq_wait() on sc_sq_ticket_wait or<br /> sc_send_wait can hang indefinitely in TASK_UNINTERRUPTIBLE state<br /> across transport teardown, pinning svc_xprt references and<br /> blocking svc_rdma_free().<br /> <br /> The close path sets XPT_CLOSE before invoking xpo_detach and both<br /> wait_event predicates include an XPT_CLOSE term, but the<br /> predicates are re-evaluated only on wakeup. sc_sq_ticket_wait has<br /> no completion-driven wake path; it is advanced solely by the<br /> chained ticket handoff inside svc_rdma_sq_wait() itself. Without<br /> an explicit wake at close, parked threads never observe<br /> XPT_CLOSE, hold their svc_xprt_get reference forever, and<br /> svc_rdma_free() blocks on xpt_ref dropping to zero.<br /> <br /> Two close entry points reach this transport. Local teardown runs<br /> svc_rdma_detach() from svc_handle_xprt() -&gt; svc_delete_xprt() -&gt;<br /> xpo_detach() on a worker thread. A remote disconnect arrives at<br /> svc_rdma_cma_handler(), which calls svc_xprt_deferred_close():<br /> that sets XPT_CLOSE and enqueues the transport but does not<br /> access either RDMA waitqueue, so a worker already parked in<br /> svc_rdma_sq_wait() never re-evaluates its predicate. With every<br /> worker parked on this transport, no thread is available to run<br /> the local teardown either, and the wake site there is<br /> unreachable.<br /> <br /> Introduce svc_rdma_xprt_deferred_close(), a thin svcrdma wrapper<br /> that calls svc_xprt_deferred_close() and then wakes both<br /> sc_sq_ticket_wait and sc_send_wait. Convert the svcrdma producers<br /> that called svc_xprt_deferred_close() directly:<br /> svc_rdma_cma_handler(), qp_event_handler(),<br /> svc_rdma_post_send_err(), svc_rdma_wc_send(), the sendto drop<br /> path, the rw completion error paths, and the recvfrom flush and<br /> read-list error paths.<br /> <br /> Wake both waitqueues from svc_rdma_detach() as well. The<br /> synchronous svc_xprt_close() path (backchannel ENOTCONN, device<br /> removal via svc_rdma_xprt_done) reaches detach without flowing<br /> through svc_xprt_deferred_close() and therefore does not invoke<br /> the new helper.<br /> <br /> [ cel: add svc_rdma_xprt_deferred_close() to complete the fix ]