net/rds: use wq_has_sleeper() in rds_cong_map_updated()
- Published
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- Fix
- Fixed in 5.10.270, 5.15.221, 6.1.188, 6.6.157, 6.12.110, and 2 more
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
Summary
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.
Timeline
- CVE published
- Record last updated
Affected versions
- Linux Linux
From 922cb17a5c812fcc9ebee249f4109db099896941 · fixed in 2a809d7896dbf18e1ecfbdd930f71c9fc298b16d; From 922cb17a5c812fcc9ebee249f4109db099896941 · fixed in fa4b98e891fda28cc0638d809c6125ec63d8319d; From 922cb17a5c812fcc9ebee249f4109db099896941 · fixed in 0e169f6a2adeb17b5577ed7e8abd642465bb50ec; From 922cb17a5c812fcc9ebee249f4109db099896941 · fixed in 42884bd8b8fd023d6a610a695bd5ddd1d5dece17; From 922cb17a5c812fcc9ebee249f4109db099896941 · fixed in a526214b9f0548ca0e53a6e0d1727d8ea9befc23; From 922cb17a5c812fcc9ebee249f4109db099896941 · fixed in bf2b8130723efcb5b86c3ddb6317c3a9b2a9cfc5; From 922cb17a5c812fcc9ebee249f4109db099896941 · fixed in 281f9fda2e06d6c211bb365a5379ed2e05cc2e21; From 922cb17a5c812fcc9ebee249f4109db099896941 · fixed in d4f484661961636eb90d287050959e613795f73a
- Linux Linux
2.6.30
- KernelLinux
From 2.6.30 · fixed in 5.10.270; From 5.11.0 · fixed in 5.15.221; From 5.16.0 · fixed in 6.1.188; From 6.2.0 · fixed in 6.6.157; From 6.7.0 · fixed in 6.12.110; From 6.13.0 · fixed in 6.18.52; From 6.19.0 · fixed in 7.2.6
References 8
git.kernel.org
- stable/c/2a809d7896dbf18e1ecfbdd930f71c9fc298b16d
- stable/c/fa4b98e891fda28cc0638d809c6125ec63d8319d
- stable/c/0e169f6a2adeb17b5577ed7e8abd642465bb50ec
- stable/c/42884bd8b8fd023d6a610a695bd5ddd1d5dece17
- stable/c/a526214b9f0548ca0e53a6e0d1727d8ea9befc23
- stable/c/bf2b8130723efcb5b86c3ddb6317c3a9b2a9cfc5
- stable/c/281f9fda2e06d6c211bb365a5379ed2e05cc2e21
- stable/c/d4f484661961636eb90d287050959e613795f73a