Skip to content
Heist/ feed
Back to feed
Unrated

CVE-2026-98072 affecting package kernel 6.6.157.1-1

Type: advisorySources: OSV

In 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_atom

Products
kernel
Affected versions
Not specified
Fixed versions
Not specified
CVEs
CVE-2026-98072
Confirmed fixed CVEs
Not specified
Updated in this feed
31 Oct 2026, 17:42 UTC · Revision 1

Source evidence

CVE-2026-98072 affecting package kernel 6.6.157.1-1

core-osv · Original source

Published 25 Sept 2026, 11:17 UTC

In 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_atom

osv:AZL-104214

kernel

Fixed versions: Not specified

Complete source record
{
  "id": "fde72d1f7b7274f2d508a5b9114c6058c49cf25a43bd7cb64729a8b21c899cf0",
  "url": "https://osv.dev/vulnerability/AZL-104214",
  "method": "structured",
  "payload": {
    "kind": "advisory",
    "title": "CVE-2026-98072 affecting package kernel 6.6.157.1-1",
    "summary": "In 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_atom",
    "evidence": "osv:AZL-104214",
    "products": [
      {
        "name": {
          "value": "kernel",
          "evidence": "/affected/0/package/name"
        },
        "prerequisites": [],
        "fixed_versions": [],
        "affected_versions": []
      }
    ],
    "severity": "unknown",
    "structured": {
      "id": "AZL-104214",
      "aliases": [
        "AZL-104214"
      ],
      "affected": [
        {
          "ranges": [
            {
              "type": "ECOSYSTEM",
              "events": [
                {
                  "introduced": "0"
                },
                {
                  "last_affected": "6.6.157.1-1"
                }
              ]
            }
          ],
          "package": {
            "name": "kernel",
            "purl": "pkg:rpm/azure-linux/kernel",
            "ecosystem": "Azure Linux:3"
          },
          "database_specific": {
            "source": "https://github.com/microsoft/AzureLinuxVulnerabilityData/blob/main/osv/AZL-104214.json"
          }
        }
      ],
      "modified": "2026-10-22T05:35:55Z",
      "provider": "osv",
      "upstream": [
        "CVE-2026-98072"
      ],
      "references": [
        "https://nvd.nist.gov/vuln/detail/CVE-2026-98072"
      ]
    },
    "related_cves": [
      {
        "value": "CVE-2026-98072",
        "evidence": "/upstream"
      }
    ],
    "security_relevant": true,
    "severity_evidence": null
  },
  "source_id": "core-osv",
  "document_id": 404419,
  "published_at": "2026-09-25T11:17:36+00:00"
}