CVE-2026-98072net/rds: use wq_has_sleeper() in release_in_xmit()
Updated under an hour ago ()
Does this affect you?
It affects Linux. Add what you run to find out whether that includes you.
No exploitation reported and no EPSS estimate yet.
Do this next
Free account, 1 product
In the Linux kernel, the following vulnerability has been resolved: net/rds: use wq_has_sleeper() in release_in_xmit() release_in_xmit() clears RDS_IN_XMIT with clear_bit_unlock() and then checks waitqueue_active() to decide whether anyone needs waking. clear_bit_unlock() is only a release operation: it orders the critical section before the bit clear, but does not order the subsequent plain load of the wait queue head after it. The waiter side does the mirror image - it adds itself to the wait queue and then tests the bit. That is the classic store-buffering pattern: the releasing CPU can read the wait queue as empty while the waiting CPU still reads the bit as set, so the sleeper is never woken. The waiters are rds_conn_shutdown() and rds_tcp_reset_callbacks(), both in uninterruptible wait_event() with no timeout. A lost wake-up strands the shutdown worker on its single-threaded workqueue until some other sender releases the bit again - and on a connection that is being torn down precisely because it failed, there may never be another sender. The barrier used to be there: release_in_xmit() did clear_bit() followed by smp_mb__after_atomic() until commit 1422f28826d2 ("rds: introduce acquire/release ordering in acquire/release_in_xmit()") folded both into clear_bit_unlock(), which strengthened the lock hand-off but silently dropped the full barrier the wake-up check depends on. The refill counterpart, release_refill() in net/rds/ib_recv.c, still carries its smp_mb__after_atomic() for exactly this reason. Use wq_has_sleeper(), which is waitqueue_active() preceded by the required full barrier.
- CVSS
- Not yet scored
- Weakness (CWE)
- Not given
- Known exploited
- Not in CISA's KEV catalog
- EPSS (exploitation in the next 30 days)
- Not loaded for this CVE
- Assigned by
- Linux
- NVD analysis
- Undergoing Analysis
- Record last updated
- Oct 3, 2026
- First seen by InfoSec Signals
- Oct 9, 2026
Affected products
Linux Linux linux:linux (from the name) | from 1e1e4316fcaeb9cd6bc56c91127e88625237dd44 before 6f552364d97cf4005c7a58f11c9f79e14e269865; from 8c378cc522aedd5fa5aa53486b43a4d552fbbd5c before a94b1dfc82454c5bc068e71c25393af674daf63b; 52287ed416a10bc3d3e204a3186d9509ab3ee634 builds before 5a806ed1eb46850ca4159a18b2a8c4b70f0c1341; 4a4dffdff9ea6201665f5d0a5042011d09bd527f builds before 3d401934b7edb3ccb07d982dabadd04c45ee307c; from 1422f28826d2a0c11e5240b3e951c9e214d8656e before ed7ee0cd0e136d02f87f13181b1a89880463c7e9; from 1422f28826d2a0c11e5240b3e951c9e214d8656e before a269795107f45adc95975a83324f8fef40bec4ce; from 1422f28826d2a0c11e5240b3e951c9e214d8656e before 3764627b30a283e611e652c4a2bb8cdc74a75a99; 1422f28826d2a0c11e5240b3e951c9e214d8656e builds before 6d0c8b7073913011459cf968cbbadd341e166bc3; and 12 more ranges | CNA record |
References
- https://git.kernel.org/stable/c/6f552364d97cf4005c7a58f11c9f79e14e269865
- https://git.kernel.org/stable/c/a94b1dfc82454c5bc068e71c25393af674daf63b
- https://git.kernel.org/stable/c/5a806ed1eb46850ca4159a18b2a8c4b70f0c1341
- https://git.kernel.org/stable/c/3d401934b7edb3ccb07d982dabadd04c45ee307c
- https://git.kernel.org/stable/c/ed7ee0cd0e136d02f87f13181b1a89880463c7e9
- https://git.kernel.org/stable/c/a269795107f45adc95975a83324f8fef40bec4ce
- https://git.kernel.org/stable/c/3764627b30a283e611e652c4a2bb8cdc74a75a99
- https://git.kernel.org/stable/c/6d0c8b7073913011459cf968cbbadd341e166bc3
The CVE record on cve.org NVD's entry
The CVE record is authoritative. Products marked “from the name” were identified from the CNA's free-text names, not a CPE, and are matched less certainly. This product uses the NVD API but is not endorsed or certified by the NVD.