CVE-2026-98069: net/rds: acquire the fastpath locks in rds_conn_shutdown()
In the Linux kernel, the following vulnerability has been resolved:
net/rds: acquire the fastpath locks in rdsconnshutdown()
rdsconnshutdown() quiesces the transmit and receive-refill paths by waiting for RDSINXMIT and RDSRECVREFILL to be sampled clear, and then runs the transport shutdown and rdsconnpathreset(). Sampling the bits clear is not the same as owning them: the moment after the waitevent() returns, rdssendxmit() can re-acquire RDSINXMIT (or rdsibrecvrefill() can re-acquire RDSRECVREFILL) and run concurrently with the teardown.
The sender does recheck the connection state after taking the lock, but that recheck is a classic store-buffering pattern: teardown writes the state and reads the bit while the sender writes the bit and reads the state. acquireinxmit() is only an acquire operation, so on weakly ordered architectures both sides can miss each other's write, and the transmit path then runs while the transport zeroes its rings (e.g. rdsibringinit()) and rdssendpathreset() rewrites the transmit state under it.
Oracle UEK fixed the same class of crashes - a 14-year tail of BUGON()s in rdsibsubsignaled(), unexpected op-codes and NULL dereferences in rdsibsendcqehandler() during failover testing - by making the teardown path acquire the fastpath bit locks instead of testing them ("rds: Make sure transmit path and connection tear-down does not run concurrently"). Ownership of a single word is decided by RMW atomicity, so no cross-variable ordering is needed.
Do the same here: take both locks before calling the transport shutdown, hold them across rdsconnpathreset(), and release them explicitly with a wake-up afterwards. Both are released with clearbitunlock(), so that the ring re-initialization done by the transport shutdown and the transmit state rewritten by rdssendpathreset() are ordered before either bit is seen clear by the next acquireinxmit() or acquirerefill().
The fastpath users of these bits - rdssendxmit() and rdsibrecvrefill() - are trylock style and back off while teardown owns the locks, so no new lock dependency is introduced for them. rdstcpresetcallbacks() is different: since the previous patch it acquires RDSINXMIT as well, and it blocks doing so, so its wait now spans the teardown instead of at most one send batch. That waiter runs from rdstcpacceptone() on the single-threaded krdsd workqueue and holds rdstcpacceptlock and tconnpathlock while it waits, so a duelling SYN accepted while its path is being torn down parks accept processing for the duration of the teardown - for TCP bounded by the (up to 5 s) drain loop in rdstcpconnpathshutdown(). An IB path's drain in rdsibconnpathshutdown() has no round cap, but no blocking waiter either: rdstcpresetcallbacks() is the only blocking acquirer of these bits and waits only on its own TCP path, and the fastpaths are trylock-and-back-off on both transports, so a long IB drain lengthens only that path's own quiesce. The window is narrow: the accept-side state check has to pass before the teardown moves the path to RDSCONNDISCONNECTING.
Because krdsd is a single global workqueue, everything else queued there - accept processing for other connections and network namespaces, and the flushworkqueue(rdswq) in rdstcplistenstop() during namespace teardown - waits behind the parked accept worker for that time. It cannot deadlock, although the waits do point at each other: the teardown blocks until the bit's holder releases it, and the holder may be that krdsd accept worker. The holder finishes without needing anything the teardown owns: the sync cancels rdstcpresetcallbacks() issues target cpsendw and cprecvw on the path's ordered cpwq, whose only execution slot is occupied by the blocked cpdownw itself, so they are pending at most and cancel without flushing - a reliance on cpwq being ordered that is now noted next to those cancels (on ---truncated---
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 6.6.158.1-1 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.1.190-1Fixed in 6.12.115-2Fixed in 7.2.12-1Fixed in 7.2.15-1 - Upgrade
Upgrade
debian/linux-6.12to a version that resolves this vulnerability.Fixed in 6.12.113-1~deb12u1 - Upgrade
Upgrade
ubuntu/linux-aws-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-1119.126~20.04.1 - Upgrade
Upgrade
ubuntu/linux-azure-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-1125.134~20.04.1 - Upgrade
Upgrade
ubuntu/linux-azure-fde-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-1124.133~20.04.1 - Upgrade
Upgrade
ubuntu/linux-gcp-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-1120.130~20.04.1 - Upgrade
Upgrade
ubuntu/linux-hwe-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-202.212~20.04.1 - Upgrade
Upgrade
ubuntu/linux-ibm-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-1113.117~20.04.1 - Upgrade
Upgrade
ubuntu/linux-intel-iotg-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-1114.120~20.04.1 - Upgrade
Upgrade
ubuntu/linux-lowlatency-hwe-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-197.207~20.04.1 - Upgrade
Upgrade
ubuntu/linux-nvidia-tegra-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-1070.72~20.04.1 - Upgrade
Upgrade
ubuntu/linux-oracle-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-1116.122~20.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-1113.117~20.04.2 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 5.15.0-202.212 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 5.15.0-1119.126 - Upgrade
Upgrade
ubuntu/linux-azureto a version that resolves this vulnerability.Fixed in 5.15.0-1125.134 - Upgrade
Upgrade
ubuntu/linux-azure-fdeto a version that resolves this vulnerability.Fixed in 5.15.0-1124.133 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 5.15.0-1120.130 - Upgrade
Upgrade
ubuntu/linux-gketo a version that resolves this vulnerability.Fixed in 5.15.0-1115.121 - Upgrade
Upgrade
ubuntu/linux-gkeopto a version that resolves this vulnerability.Fixed in 5.15.0-1102.110 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 5.15.0-1113.117 - Upgrade
Upgrade
ubuntu/linux-intel-iotgto a version that resolves this vulnerability.Fixed in 5.15.0-1114.120 - Upgrade
Upgrade
ubuntu/linux-kvmto a version that resolves this vulnerability.Fixed in 5.15.0-1111.116 - Upgrade
Upgrade
ubuntu/linux-lowlatencyto a version that resolves this vulnerability.Fixed in 5.15.0-197.207 - Upgrade
Upgrade
ubuntu/linux-nvidiato a version that resolves this vulnerability.Fixed in 5.15.0-1114.115 - Upgrade
Upgrade
ubuntu/linux-nvidia-tegrato a version that resolves this vulnerability.Fixed in 5.15.0-1070.72 - Upgrade
Upgrade
ubuntu/linux-nvidia-tegra-igxto a version that resolves this vulnerability.Fixed in 5.15.0-1059.59 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 5.15.0-1116.122 - Upgrade
Upgrade
ubuntu/linux-bluefieldto a version that resolves this vulnerability.Fixed in 5.15.0-1103.105 - Upgrade
Upgrade
ubuntu/linux-intel-iot-realtimeto a version that resolves this vulnerability.Fixed in 5.15.0-1111.115 - Upgrade
Upgrade
ubuntu/linux-realtimeto a version that resolves this vulnerability.Fixed in 5.15.0-1118.127 - Upgrade
Upgrade
ubuntu/linux-aws-fipsto a version that resolves this vulnerability.Fixed in 5.15.0-1119.126+fips1 - Upgrade
Upgrade
ubuntu/linux-azure-fipsto a version that resolves this vulnerability.Fixed in 5.15.0-1125.134+fips1 - Upgrade
Upgrade
ubuntu/linux-fipsto a version that resolves this vulnerability.Fixed in 5.15.0-202.212+fips1 - Upgrade
Upgrade
ubuntu/linux-gcp-fipsto a version that resolves this vulnerability.Fixed in 5.15.0-1120.130+fips1 - Upgrade
Upgrade
ubuntu/linux-hwe-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42~24.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1~24.04.1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 7.0.0-42.42 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 7.0.0-1016.17 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 7.0.0-1016.18 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oem-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 7.0.0-1015.16 - Upgrade
Upgrade
ubuntu/linux-riscvto a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1
Event History
Frequently Asked Questions
Which systems are realistically exposed to this race condition?
Linux systems using RDS connections are exposed when connection shutdown can overlap with the transmit path or the receive-refill path. The issue is particularly relevant on weakly ordered architectures, where both teardown and a concurrent sender can miss each other's state updates.
What conditions are needed for the issue to occur?
A shutdown must race with rds_send_xmit() acquiring RDS_IN_XMIT or rds_ib_recv_refill() acquiring RDS_RECV_REFILL after shutdown has observed the corresponding bit clear. The concurrent path can then access transport rings or transmit state while teardown is zeroing or resetting them.
What symptoms could indicate that a system has encountered this issue?
Reported outcomes include BUG_ON() failures in rds_ib_sub_signaled(), unexpected operation codes, and NULL-pointer dereferences. These failures are associated with transmit or receive-refill activity running concurrently with RDS transport teardown.