CVE-2026-90081

net/rds: use wq_has_sleeper() in rds_cong_map_updated()

N/A
Published: September 17, 2026 at 04:05 PM UTC
Updated: October 19, 2026 at 09:18 AM UTC
1 product affected across 1 vendorLinux Kernel

Using Linux by Linux?

Get instant alerts when new vulnerabilities affect Linux - before attackers find them.

Real-time alertsTrack your software stackFree plan available
Severity
N/A
Exploit prediction
EPSS 0.2%

Description

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.

Affected

Our own answer: ranges merged, affected separated from platform-only, with confidence and review flags.

2.6.30922cb17a5c812fcc9ebee249f4109db099896941
Vendor states this is fixed in 0e169f6a2adeb17b5577ed7e8abd642465bb50ec (fixed)
Vendor states this is fixed in 281f9fda2e06d6c211bb365a5379ed2e05cc2e21 (fixed)
Vendor states this is fixed in 2a809d7896dbf18e1ecfbdd930f71c9fc298b16d (fixed)
Vendor states this is fixed in 42884bd8b8fd023d6a610a695bd5ddd1d5dece17 (fixed)
Vendor states this is fixed in a526214b9f0548ca0e53a6e0d1727d8ea9befc23 (fixed)
Vendor states this is fixed in bf2b8130723efcb5b86c3ddb6317c3a9b2a9cfc5 (fixed)
Vendor states this is fixed in d4f484661961636eb90d287050959e613795f73a (fixed)
Vendor states this is fixed in fa4b98e891fda28cc0638d809c6125ec63d8319d (fixed)
Vendor states this is fixed in 2.6.30 (unaffected)
Vendor states this is fixed in 5.10.270 (unaffected)
Vendor states this is fixed in 5.15.221 (unaffected)
Vendor states this is fixed in 6.1.188 (unaffected)
Vendor states this is fixed in 6.12.110 (unaffected)
Vendor states this is fixed in 6.18.52 (unaffected)
Vendor states this is fixed in 6.6.157 (unaffected)
Vendor states this is fixed in 7.2.6 (unaffected)
Vendor states this is fixed in 7.3 (unaffected)
Vendor states this is fixed in 7.3-rc1 (unaffected)

Remediation

No guide yet

No remediation guidance has been written for this CVE yet, and no fixed version or vendor advisory is recorded against it.

Quick Info

StatusRECEIVED

Get alerted

Stop reading CVE feeds looking for your own stack

Track the products you run and VulnTracker tells you when a new CVE affects them — with what is known about fixing it, and nothing about the rest.

Free plan, no card