CVE-2026-98257
High · 7.5CVSS
7.5
EPSS
0.5%
Published
Oct 6, 2026
CISA due date
—
Cloudanix analysis
A flaw in Linux kernel networking code can cause certain network connections to freeze permanently when talking to an older system, potentially disrupting services until the system is updated.
- Exploitation
- Remote Unauthenticated
- Attacker needs
- None
- Complexity
- Low
- Impact
- Denial Of Service
- Component
- OS kernel
- Class
- Race Condition
- Remediation
- Upgrade
- Effort
- Medium
- Patch risk
- Low
What it actually does
Deadlock in RDS/IB connection teardown: rds_ib_cm_connect_complete holds c_cm_lock and calls rds_conn_destroy on version mismatch, causing the shutdown work item to block forever on the same lock and stall the connection workqueues.
Why it matters to the business
Systems using RDS over RDMA can experience permanent loss of network connectivity for affected connections, leading to service disruption; the issue has low exploitation probability and no known ransomware use 17 days after disclosure.
How an attack unfolds
An attacker initiates an RDMA-CM connection request advertising an RDS protocol version older than RDS_PROTOCOL_COMPAT_VERSION; the event handler takes the lock, calls the unsafe destroy path, and the resulting circular wait between the handler and the shutdown worker permanently stalls RDS workqueues.
How to fix it
Apply the upstream kernel patch that replaces the rds_conn_destroy call with rds_conn_drop in rds_ib_cm_connect_complete; rebuild and deploy the fixed kernel on all systems using RDS/IB.
How to confirm the fix worked
Confirm the patch is present by inspecting the rds_ib_cm_connect_complete function for the rds_conn_drop call on version mismatch; test by forcing an old-protocol connection attempt and verifying workqueues remain responsive.
Typical attack path
- Attacker sends RDMA-CM connection request with incompatible old RDS protocol version
- rds_ib_cm_connect_complete acquires conn->c_cm_lock
- Handler invokes rds_conn_destroy instead of rds_conn_drop
- Shutdown work blocks on the held lock, creating deadlock
- RDS connection workqueues stall indefinitely
How to detect it
Review kernel logs and workqueue traces for stalled RDS connection shutdown tasks or repeated lock contention involving c_cm_lock and cp_down_w; correlate with RDMA-CM events showing protocol version negotiation failures.
What your security team should do
- Prioritize patching kernel RDS/IB code on any hosts that enable RDS over InfiniBand
- Monitor EPSS and threat intel for any rise in exploitation activity
- Consider disabling RDS/IB if the protocol is not required
The record
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.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|