CVE-2026-98072

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.