GHSA-6XGX-8JC3-WHPQ
Vulnerability from github – Published: 2026-09-25 12:31 – Updated: 2026-09-25 12:31In 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.
{
"affected": [],
"aliases": [
"CVE-2026-98072"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-25T11:17:36Z",
"severity": null
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/rds: use wq_has_sleeper() in release_in_xmit()\n\nrelease_in_xmit() clears RDS_IN_XMIT with clear_bit_unlock() and then\nchecks waitqueue_active() to decide whether anyone needs waking.\nclear_bit_unlock() is only a release operation: it orders the\ncritical section before the bit clear, but does not order the\nsubsequent plain load of the wait queue head after it. The waiter\nside does the mirror image - it adds itself to the wait queue and\nthen tests the bit. That is the classic store-buffering pattern: the\nreleasing CPU can read the wait queue as empty while the waiting CPU\nstill reads the bit as set, so the sleeper is never woken.\n\nThe waiters are rds_conn_shutdown() and rds_tcp_reset_callbacks(),\nboth in uninterruptible wait_event() with no timeout. A lost wake-up\nstrands the shutdown worker on its single-threaded workqueue until\nsome other sender releases the bit again - and on a connection that\nis being torn down precisely because it failed, there may never be\nanother sender.\n\nThe barrier used to be there: release_in_xmit() did clear_bit()\nfollowed by smp_mb__after_atomic() until commit 1422f28826d2 (\"rds:\nintroduce acquire/release ordering in acquire/release_in_xmit()\")\nfolded both into clear_bit_unlock(), which strengthened the lock\nhand-off but silently dropped the full barrier the wake-up check\ndepends on. The refill counterpart, release_refill() in\nnet/rds/ib_recv.c, still carries its smp_mb__after_atomic() for\nexactly this reason.\n\nUse wq_has_sleeper(), which is waitqueue_active() preceded by the\nrequired full barrier.",
"id": "GHSA-6xgx-8jc3-whpq",
"modified": "2026-09-25T12:31:35Z",
"published": "2026-09-25T12:31:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-98072"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3764627b30a283e611e652c4a2bb8cdc74a75a99"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6d0c8b7073913011459cf968cbbadd341e166bc3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a269795107f45adc95975a83324f8fef40bec4ce"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ed7ee0cd0e136d02f87f13181b1a89880463c7e9"
}
],
"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.