GHSA-23R9-76MG-5GPP
Vulnerability from github – Published: 2026-09-17 18:31 – Updated: 2026-09-17 18:31In 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": [],
"aliases": [
"CVE-2026-90081"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-17T17:16:57Z",
"severity": null
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/rds: use wq_has_sleeper() in rds_cong_map_updated()\n\nrds_cong_map_updated() runs after a peer\u0027s congestion map has been\nrewritten (by rds_tcp_cong_recv() and rds_ib_cong_recv(), or the\nclear-all in the loopback and IB send-completion paths). It bumps\nrds_cong_generation and then checks waitqueue_active() on\nmap-\u003em_waitq and on rds_poll_waitq to decide whether anyone needs\nwaking. atomic_inc() carries no ordering and waitqueue_active() is a\nplain load, so nothing orders the map and generation stores before\nthe wait queue reads. The waiters do the mirror image: rds_cong_wait()\nadds itself to m_waitq and then tests the port bit, and rds_poll()\nregisters on rds_poll_waitq and then reads the generation. That is\nthe store-buffering pattern described above waitqueue_active() in\ninclude/linux/wait.h - the updater can observe an empty wait queue\nwhile the waiter still observes the port as congested, and no wake-up\nis issued.\n\nrds_cong_wait() is an interruptible sleep with no timeout, so a\nsender blocked on a congested port stays blocked until the next\ncongestion update from that peer arrives or a signal is delivered.\nA poll() waiter misses the map-updated notification the same way.\n\nUse wq_has_sleeper(), which is waitqueue_active() preceded by the\nrequired full barrier, as rds_tcp_state_change() already does for\nthe same pattern.",
"id": "GHSA-23r9-76mg-5gpp",
"modified": "2026-09-17T18:31:50Z",
"published": "2026-09-17T18:31:50Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-90081"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0e169f6a2adeb17b5577ed7e8abd642465bb50ec"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/281f9fda2e06d6c211bb365a5379ed2e05cc2e21"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2a809d7896dbf18e1ecfbdd930f71c9fc298b16d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/42884bd8b8fd023d6a610a695bd5ddd1d5dece17"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a526214b9f0548ca0e53a6e0d1727d8ea9befc23"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bf2b8130723efcb5b86c3ddb6317c3a9b2a9cfc5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d4f484661961636eb90d287050959e613795f73a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fa4b98e891fda28cc0638d809c6125ec63d8319d"
}
],
"schema_version": "1.4.0",
"severity": []
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.