Description
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.
Published: 2026-09-25
Score: n/a
EPSS: n/a
KEV: No
Impact: Denial of Service
Action: Patch Immediately
AI Analysis

Impact

An unsynchronized memory ordering bug in the Linux kernel’s RDS module allows a lost wake‑up condition in release_in_xmit(). Clearing the RDS_IN_XMIT flag without a full memory barrier can cause the receiving CPU to miss the wake‑up, leaving waiters such as rds_conn_shutdown() and rds_tcp_reset_callbacks() stuck in an uninterruptible wait_event. The consequence is that a shutdown worker or reset callback can remain hung indefinitely, potentially exhausting kernel resources and preventing RDS connections from terminating properly. This flaw is a classic data‑race and synchronization issue, categorized as CWE-754 and CWE-362.

Affected Systems

Both vendor strings identify the Linux kernel as the affected product. No specific kernel version list is provided by the CNA, so any Linux kernel image built before the commit that replaces clear_bit_unlock() with wq_has_sleeper() in release_in_xmit() is potentially vulnerable. The CPE string indicates that all Linux kernel releases may be affected until that patch is applied.

Risk and Exploitability

The CVSS score is not disclosed and EPSS is unavailable, so the exact severity cannot be quantified. The flaw is not listed in CISA’s KEV catalog, implying no known wide‑scale exploitation. Based on the description, the attack vector is likely local or requires privileged remote code that can send crafted RDS packets; it does not appear to be remotely exploitable over the network without kernel access. Nonetheless, failing to respond to a lost wake‑up can lead to a kernel‑level denial of service, making the risk significant for systems that use RDS for critical data transfers.

Generated by OpenCVE AI on September 25, 2026 at 16:16 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Upgrade the kernel to a version that incorporates the patch commit which replaces clear_bit_unlock() in release_in_xmit() with wq_has_sleeper() to enforce the necessary memory barrier.
  • If an immediate kernel upgrade is not possible, disable or remove RDS support on the affected nodes to eliminate the race condition from the code path.
  • Continuously monitor RDS connections and kernel worker states; if a worker becomes unresponsive due to a lost wake‑up, restart the affected service or the entire node to recover from the denial of service.

Generated by OpenCVE AI on September 25, 2026 at 16:16 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Fri, 25 Sep 2026 16:45:00 +0000

Type Values Removed Values Added
Weaknesses CWE-362
CWE-754

Fri, 25 Sep 2026 10:30:00 +0000

Type Values Removed Values Added
Description 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.
Title net/rds: use wq_has_sleeper() in release_in_xmit()
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-09-25T10:24:12.675Z

Reserved: 2026-09-25T10:19:56.074Z

Link: CVE-2026-98072

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-09-25T11:17:36.450

Modified: 2026-09-25T11:17:36.450

Link: CVE-2026-98072

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-09-25T16:30:15Z

Weaknesses
  • CWE-362

    Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')

  • CWE-754

    Improper Check for Unusual or Exceptional Conditions