{
  "affected": [
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:12",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:13",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:14",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "details": "In the Linux kernel, the following vulnerability has been resolved:  net/rds: acquire RDS_IN_XMIT in rds_tcp_reset_callbacks()  rds_tcp_reset_callbacks() quiesces the transmit path by setting the path state to RDS_CONN_RESETTING and then waiting for RDS_IN_XMIT to be sampled clear before swapping the underlying socket and calling rds_send_path_reset().  Sampling the bit clear is not the same as owning it: rds_send_xmit() can re-acquire RDS_IN_XMIT right after the wait_event() returns.  Its state recheck after taking the lock is a store-buffering pattern (the resetter writes the state and reads the bit, the sender writes the bit and reads the state) and acquire_in_xmit() is only an acquire operation, so on weakly ordered architectures both sides can miss each other's write and the transmit path then runs concurrently with rds_send_path_reset() rewriting cp_xmit_* state - which is exactly what the comment above rds_send_path_reset() tells its callers to prevent.  Take the lock instead, hold it across the socket swap and rds_send_path_reset(), and release it with a wake-up at the end.  The lock-ordering constraint documented above the wait still holds: the lock is acquired before lock_sock(), so a sender inside tcp_sendmsg() can never be waited on while we hold the socket lock.  Two details of the old code go away with the same change:   - t_sock is now read only after the lock is acquired.  The old code    cached it before waiting; the teardown in rds_conn_shutdown()    releases that socket and clears t_sock, so a pointer cached before    the wait can be stale by the time the accept path resumes.  Reading    it under RDS_IN_XMIT is what makes the exclusion complete once the    teardown owns the same lock, which the next patch arranges; until    then the teardown still only samples the bit, and the two paths    remain as exposed to each other as they are today.   - The old !osock early path called rds_send_path_reset() with no    serialization at all.  It now runs under the lock like the normal    path.  The conditional RDS_CONN_RESETTING transition of the    previous patch happens before the socket check either way: a path    found without a socket is either still connecting (its reconnect    worker blocked on t_conn_path_lock) and legitimately goes    RESETTING -\u003e UP on the new socket, or it has been torn down    meanwhile and is dropped.  The in-function comment describing the old wait-based quiesce is rewritten to describe the lock-based one, and the stale block comment above the function (which still described a return value and an incomplete list of t_sock writers) is refreshed to name all four writers - the connect, accept, teardown and swap paths - and what serializes each of them.",
  "id": "DEBIAN-CVE-2026-98070",
  "modified": "2026-09-26T04:47:35.381896801Z",
  "published": "2026-09-25T11:17:36.193Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://security-tracker.debian.org/tracker/CVE-2026-98070"
    }
  ],
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "upstream": [
    "CVE-2026-98070"
  ]
}