PT-2026-98733 · Linux · Linux
CVE-2026-98070
·
Published
2026-09-25
·
Updated
2026-09-26
CVSS v3.1
8.1
High
| Vector | AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H |
In the Linux kernel, the following vulnerability has been resolved:
net/rds: acquire RDS IN XMIT in rds tcp reset callbacks()
rds tcp reset callbacks() quiesces the transmit path by setting the
path state to RDS CONN RESETTING and then waiting for RDS IN XMIT to
be sampled clear before swapping the underlying socket and calling
rds send path reset().
Sampling the bit clear is not the same as owning it: rds send xmit()
can re-acquire RDS IN XMIT right after the wait event() returns. Its
state recheck after taking the lock is a store-buffering pattern (the
resetter writes the state and reads the bit, the sender writes the
bit and reads the state) and acquire in xmit() is only an acquire
operation, so on weakly ordered architectures both sides can miss
each other's write and the transmit path then runs concurrently with
rds send path reset() rewriting cp xmit * state - which is exactly
what the comment above rds send path reset() tells its callers to
prevent.
Take the lock instead, hold it across the socket swap and
rds send path reset(), and release it with a wake-up at the end. The
lock-ordering constraint documented above the wait still holds: the
lock is acquired before lock sock(), so a sender inside tcp sendmsg()
can never be waited on while we hold the socket lock.
Two details of the old code go away with the same change:
-
t sock is now read only after the lock is acquired. The old code cached it before waiting; the teardown in rds conn shutdown() releases that socket and clears t sock, so a pointer cached before the wait can be stale by the time the accept path resumes. Reading it under RDS IN XMIT is what makes the exclusion complete once the teardown owns the same lock, which the next patch arranges; until then the teardown still only samples the bit, and the two paths remain as exposed to each other as they are today.
-
The old !osock early path called rds send path reset() with no serialization at all. It now runs under the lock like the normal path. The conditional RDS CONN RESETTING transition of the previous patch happens before the socket check either way: a path found without a socket is either still connecting (its reconnect worker blocked on t conn path lock) and legitimately goes RESETTING -> UP on the new socket, or it has been torn down meanwhile and is dropped.
The in-function comment describing the old wait-based quiesce is
rewritten to describe the lock-based one, and the stale block comment
above the function (which still described a return value and an
incomplete list of t sock writers) is refreshed to name all four
writers - the connect, accept, teardown and swap paths - and what
serializes each of them.
Fix
Found an issue in the description? Have something to add? Feel free to write us 👾
Related Identifiers
Affected Products
Linux