CVE-2026-90081 in Linux
Summary
by MITRE • 09/17/2026
In the Linux kernel, the following vulnerability has been resolved:
net/rds: use wq_has_sleeper() in rds_cong_map_updated()
rds_cong_map_updated() runs after a peer's congestion map has been rewritten (by rds_tcp_cong_recv() and rds_ib_cong_recv(), or the clear-all in the loopback and IB send-completion paths). It bumps rds_cong_generation and then checks waitqueue_active() on map->m_waitq and on rds_poll_waitq to decide whether anyone needs waking. atomic_inc() carries no ordering and waitqueue_active() is a plain load, so nothing orders the map and generation stores before the wait queue reads. The waiters do the mirror image: rds_cong_wait() adds itself to m_waitq and then tests the port bit, and rds_poll() registers on rds_poll_waitq and then reads the generation. That is the store-buffering pattern described above waitqueue_active() in include/linux/wait.h - the updater can observe an empty wait queue while the waiter still observes the port as congested, and no wake-up is issued.
rds_cong_wait() is an interruptible sleep with no timeout, so a sender blocked on a congested port stays blocked until the next congestion update from that peer arrives or a signal is delivered. A poll() waiter misses the map-updated notification the same way.
Use wq_has_sleeper(), which is waitqueue_active() preceded by the required full barrier, as rds_tcp_state_change() already does for the same pattern.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/17/2026
The vulnerability identified in the Linux kernel's Reliable Datagram Sockets (RDS) subsystem stems from a critical race condition involving memory ordering and synchronization primitives within the congestion control mechanism. Specifically, the function rds_cong_map_updated is responsible for notifying waiting processes when a peer’s congestion map has been rewritten by functions such as rds_tcp_cong_recv or rds_ib_cong_recv. The core technical flaw lies in the sequence of operations performed during this update process. After incrementing the rds_cong_generation counter, the code checks waitqueue_active on both map->m_waitq and rds_poll_waitq to determine if any threads are waiting for a state change. However, atomic_inc carries no memory ordering guarantees, and waitqueue_active is implemented as a plain load operation without an accompanying memory barrier. This lack of synchronization means there is no guarantee that the stores updating the congestion map and generation counter will be visible to other CPUs before the read operations on the wait queues are executed.
This architectural oversight creates a classic store-buffering race condition where the updater can observe an empty wait queue while, from the perspective of waiting threads, the port remains marked as congested because they have not yet seen the updated generation count or map state. Consequently, no wake-up signal is issued to the sleeping processes. The mirror image of this flaw exists in the waiter logic within rds_cong_wait and rds_poll functions. These routines add themselves to the wait queue before testing the port bit or reading the generation counter. Due to the absence of proper memory barriers on both sides of the interaction, a sender blocked on a congested port may remain indefinitely asleep even after congestion has been resolved by the peer. This results in a denial-of-service scenario where legitimate network operations are stalled without timeout, relying solely on subsequent updates or external signals to resume execution.
The operational impact of this vulnerability is significant for systems utilizing RDS for high-performance networking, particularly in environments requiring low-latency communication such as database clustering or distributed computing frameworks. The inability to properly wake up blocked threads leads to resource exhaustion and application hangs. Since rds_cong_wait operates with an interruptible sleep but no timeout, the affected processes are effectively frozen until a new congestion update arrives from the peer or a signal is delivered by another process. This behavior violates expected protocol semantics where state changes should promptly trigger appropriate responses in waiting threads. The issue affects both TCP and InfiniBand transport layers within RDS, as well as loopback paths, indicating a systemic flaw in how synchronization primitives are applied across different code paths handling congestion notifications.
To mitigate this vulnerability, the Linux kernel developers have implemented a fix that replaces waitqueue_active with wq_has_sleeper. This function is specifically designed to handle such scenarios by preceding the check for sleepers with the required full memory barrier. By ensuring that all prior stores to the map and generation variables are globally visible before checking if any threads are sleeping, the race condition is eliminated. This approach mirrors existing correct implementations in rds_tcp_state_change, which already utilizes this pattern successfully. The adoption of wq_has_sleeper ensures proper ordering between the updater writing new congestion states and waiters reading those states, thereby guaranteeing that wake-up signals are issued correctly when conditions change.
From a classification perspective, this vulnerability aligns with CWE-362, Concurrent Execution using Shared Resource with Improper Synchronization, commonly known as a race condition. The specific mechanism involves improper synchronization of shared data structures across multiple execution contexts without adequate memory barriers to enforce visibility and ordering constraints. In the context of the MITRE ATT&CK framework, this flaw could be leveraged in techniques related to Denial of Service (T1499) by causing application hangs or resource exhaustion through deliberate congestion triggering that fails to resolve due to the synchronization bug. Furthermore, it relates to CWE-820, Missing Synchronization Primitive, as the code failed to utilize appropriate barriers to coordinate access to shared state variables between producer and consumer threads within the kernel network stack.
The resolution underscores the importance of rigorous memory ordering practices in kernel development, particularly when dealing with wait queues and atomic counters that interact across CPU cores. Developers must ensure that any read or write operations on shared data structures involved in synchronization protocols are protected by appropriate barriers to prevent subtle timing-dependent failures. This incident serves as a reminder that standard library functions like waitqueue_active may not always provide the necessary semantic guarantees for complex concurrent scenarios, necessitating the use of specialized primitives like wq_has_sleeper that explicitly enforce memory ordering constraints. Proper implementation of these synchronization mechanisms is essential for maintaining system stability and performance in high-throughput network environments relying on RDS protocols.