CVE-2026-98068 Overview
CVE-2026-98068 is a race condition in the Linux kernel's Reliable Datagram Sockets (RDS) subsystem. The flaw lives in rds_conn_shutdown() within the net/rds TCP transport. During teardown, the function accepted both RDS_CONN_DISCONNECTING and RDS_CONN_ERROR as valid starting states for its final transition to RDS_CONN_DOWN. This behavior consumed a concurrent drop request issued by rds_conn_path_drop(), allowing a freshly accepted TCP socket installed by rds_tcp_accept_one() to persist without teardown. The result is a wedged connection path stuck in RDS_CONN_DOWN, an unreaped socket on rds_tcp_tc_list, and a growing receive queue the peer cannot drain.
Critical Impact
A concurrent drop racing an RDS shutdown can leave a live TCP socket installed with armed callbacks while the connection path is wedged in RDS_CONN_DOWN, blocking peer traffic until an unrelated event restarts the path.
Affected Products
- Linux kernel net/rds subsystem (TCP transport)
- Stable kernel branches referenced by commits 260c6308, 29415613, 4cb9b6d3, and bd1cb197
- Distributions shipping affected stable kernels with RDS-TCP enabled
Discovery Timeline
- 2026-09-25 - CVE-2026-98068 published to NVD
- 2026-09-30 - Last updated in NVD database
Technical Details for CVE-2026-98068
Vulnerability Analysis
The vulnerability is a race condition [CWE-362] between RDS connection shutdown and inbound socket acceptance. rds_conn_shutdown() moves a path from RDS_CONN_DISCONNECTING to RDS_CONN_DOWN and also accepted RDS_CONN_ERROR as a valid start state. This tolerance exists so a FIN handled in softirq context during teardown does not spill into an error path.
The side effect is that the final transition silently consumes an RDS_CONN_ERROR set by rds_conn_path_drop(). When a drop queues cp_down_w and the in-flight shutdown reaches RDS_CONN_DOWN first, the queued pass executes against a path already down and becomes a no-op. The dropper's teardown work is lost.
rds_tcp_accept_one() triggers the hazard. Its path claim transitions RDS_CONN_DOWN to RDS_CONN_CONNECTING. A concurrent drop can inject RDS_CONN_ERROR between the claim and the state check. The accept proceeds with rds_tcp_set_callbacks() while an older teardown continues. rds_connect_path_complete() then fails and drops the path again. If the in-flight shutdown consumes that drop, the installed socket is never torn down.
Root Cause
The root cause is overly permissive state acceptance in the final cmpxchg of rds_conn_shutdown(). By accepting both DISCONNECTING and ERROR as source states, the function conflates a benign softirq FIN with an active teardown request from another writer. Fallout includes a leaked rds_tcp_connection on rds_tcp_tc_list and a reconnect timer that can fire after rds_conn_path_destroy() frees the path.
Attack Vector
Triggering the race requires concurrent RDS-TCP traffic, inbound accept activity, and a drop event such as a softirq FIN or administrative reset. The condition is local to the kernel's networking stack and is observable to a peer as a stalled RDS connection whose receive queue grows without being read. The upstream commit message notes the race was reproduced with widened race windows rather than through a remote exploit primitive. See the upstream fix commit 260c6308 for the corrected state machine.
Detection Methods for CVE-2026-98068
Indicators of Compromise
- RDS-TCP connection paths persistently stuck in RDS_CONN_DOWN despite active peer traffic.
- rds_tcp_connection entries on rds_tcp_tc_list referencing sockets with no associated active path.
- Peer-side TCP sockets reporting ever-growing receive queues with no application reads.
- Kernel WARN_ON from rds_conn_path_destroy() observing cp_conn_w still armed during netns teardown or module unload.
Detection Strategies
- Monitor /proc/net/rds/connections and transport-specific debug output for paths that remain down while peers continue to send.
- Collect ss -tnm snapshots on RDS-TCP peers to flag sockets whose Recv-Q grows without draining.
- Alert on kernel log entries containing rds_conn_path_destroy warnings or RDS state transition anomalies.
Monitoring Recommendations
- Centralize kernel ring buffer and syslog data for hosts running RDS-TCP workloads and build detections for RDS warnings.
- Track reconnect timer firings and connection reset frequency per RDS path to identify wedged connections.
- Correlate netns teardown and module unload events with RDS warnings to catch the destroy-time race.
How to Mitigate CVE-2026-98068
Immediate Actions Required
- Apply the upstream stable kernel update that restricts the final transition in rds_conn_shutdown() to DISCONNECTING -> DOWN.
- If patching is not immediately possible, disable the RDS module on systems that do not require it using modprobe -r rds_tcp rds.
- Blacklist RDS loading on hosts where the subsystem is unused by adding entries under /etc/modprobe.d/.
Patch Information
The fix narrows rds_conn_shutdown() so its final transition only accepts RDS_CONN_DISCONNECTING. When the transition fails because the path is in RDS_CONN_ERROR, the function cancels the reconnect timer, clears RDS_RECONNECT_PENDING, and returns to let the queued drop pass finish teardown. Reference commits: 260c6308, 29415613, 4cb9b6d3, and bd1cb197.
Workarounds
- Prevent RDS module autoload on systems that do not use RDS-TCP by blacklisting rds and rds_tcp.
- Restrict unprivileged socket creation of AF_RDS via distribution-specific LSM or seccomp policies where applicable.
- Monitor for stuck RDS paths and recycle affected hosts or restart RDS workloads as a temporary recovery step.
# Disable RDS modules on hosts that do not need the subsystem
cat <<'EOF' | sudo tee /etc/modprobe.d/disable-rds.conf
blacklist rds
blacklist rds_tcp
blacklist rds_rdma
install rds /bin/true
EOF
sudo modprobe -r rds_tcp rds_rdma rds 2>/dev/null || true
sudo update-initramfs -u
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

