Description

In the Linux kernel, the following vulnerability has been resolved: rds: ib: use rds_conn_drop() on protocol version mismatch rds_ib_cm_connect_complete() runs from the RDMA-CM event handler with conn->c_cm_lock held. When the peer negotiates a protocol version older than RDS_PROTOCOL_COMPAT_VERSION, the handler calls rds_conn_destroy(), which is only safe in the rmmod path: it synchronously tears the connection down and flush_work()es the shutdown work cp_down_w. That shutdown work (rds_conn_shutdown()) needs cp_cm_lock, which is the very lock the event handler still holds, so the flush never completes: the two workers wait on each other and the RDS connection workqueues stall for good. All other RDMA-CM failure paths (REJECTED, CONNECT_ERROR, DISCONNECTED) use rds_conn_drop(), which marks the connection RDS_CONN_ERROR and schedules the shutdown work asynchronously. Use it here as well.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-10-06T09:18:14.540Z",
  "pubdate": "2026-10-06T09:18:14.540Z",
  "executiveSummary": "A deadlock vulnerability exists in the Reliable Datagram Sockets (RDS) over InfiniBand (IB) implementation within the Linux kernel.\nThe vulnerability occurs due to improper connection teardown handling when an RDMA-CM connection event reports a protocol version mismatch.\nAn attacker capable of initiating RDMA connections can trigger a kernel deadlock, leading to a permanent stall of RDS connection workqueues and a denial-of-service condition.\nThe issue stems from the synchronous invocation of rds_conn_destroy() while holding the c_cm_lock, which conflicts with internal shutdown mechanisms requiring the same lock.\nThis vulnerability affects the RDS kernel module. Exploitation does not require authentication but necessitates the ability to participate in RDMA-CM connection negotiations.",
  "technicalDetails": "The root cause of this vulnerability is an improper synchronization strategy within the rds_ib_cm_connect_complete() function during an RDMA-CM connection event handler execution.\nWhen a peer system requests a protocol version older than the required RDS_PROTOCOL_COMPAT_VERSION, the kernel initiates a teardown procedure. Previously, the handler invoked rds_conn_destroy() to terminate the connection.\nThe function rds_conn_destroy() is designed for use during module removal (rmmod) and performs a synchronous teardown, including a call to flush_work() to force the completion of the rds_conn_shutdown() work item.\nA critical circular dependency occurs because rds_conn_shutdown() requires the acquisition of the c_cm_lock to proceed. However, the event handler invoked rds_conn_destroy() while already holding the c_cm_lock.\nConsequently, the kernel enters a deadlock state: the workqueue thread waits for the c_cm_lock held by the event handler, while the event handler waits for the workqueue thread to flush the shutdown task. This results in the RDS connection workqueues becoming permanently stalled.\nAttackers can trigger this condition by intentionally negotiating an unsupported protocol version during the RDMA connection setup phase. By initiating multiple connections that fail this validation check, an attacker can consume system resources and stall the RDS subsystem, effectively denying service to legitimate RDS-based network traffic.\nThis flaw is specific to the ib/rds implementation of the Linux kernel. Unlike other RDMA-CM failure paths, such as REJECTED, CONNECT_ERROR, or DISCONNECTED, which correctly utilize rds_conn_drop(), the protocol version mismatch path bypassed this asynchronous safety mechanism.\nThe remediation involves replacing the synchronous rds_conn_destroy() call with rds_conn_drop(). Unlike its counterpart, rds_conn_drop() marks the connection state as RDS_CONN_ERROR and schedules the shutdown work asynchronously without requiring immediate lock acquisition or synchronous flushing, thereby resolving the deadlock condition."
}