CVE-2026-98070 (GCVE-0-2026-98070)

Vulnerability from cvelistv5 – Published: 2026-09-25 10:24 – Updated: 2026-09-25 14:42
VLAI
Title
net/rds: acquire RDS_IN_XMIT in rds_tcp_reset_callbacks()
Summary
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 -> 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.
Severity
8.1 (High)
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
Assigner
References
Impacted products
Vendor Product Version CPE status
Linux Linux Affected: 335b48d980f631fbc5b233cbb3625ac0c86d67cb , < d625112564c3e980e02504270222b49b82690cee (git)
Affected: 335b48d980f631fbc5b233cbb3625ac0c86d67cb , < 8e4c3b7844c906c7097b4cfedd9dd1f48c9a6a92 (git)
Affected: 335b48d980f631fbc5b233cbb3625ac0c86d67cb , < 062d9e008c67289e8e1b221ecdd8f9d60566d012 (git)
Affected: 335b48d980f631fbc5b233cbb3625ac0c86d67cb , < 02c5f9dc2efd823e061954d564ce00bacd1bebeb (git)
guessed Create a notification for this product.
Linux Linux Affected: 4.7
Unaffected: 0 , < 4.7 (semver)
Unaffected: 6.12.111 , ≤ 6.12.* (semver)
Unaffected: 6.18.53 , ≤ 6.18.* (semver)
Unaffected: 7.2.7 , ≤ 7.2.* (semver)
Unaffected: 7.3-rc2 , ≤ * (original_commit_for_fix)
guessed Create a notification for this product.
Show details on NVD website
To clipboard 

{
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "net/rds/tcp.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "d625112564c3e980e02504270222b49b82690cee",
              "status": "affected",
              "version": "335b48d980f631fbc5b233cbb3625ac0c86d67cb",
              "versionType": "git"
            },
            {
              "lessThan": "8e4c3b7844c906c7097b4cfedd9dd1f48c9a6a92",
              "status": "affected",
              "version": "335b48d980f631fbc5b233cbb3625ac0c86d67cb",
              "versionType": "git"
            },
            {
              "lessThan": "062d9e008c67289e8e1b221ecdd8f9d60566d012",
              "status": "affected",
              "version": "335b48d980f631fbc5b233cbb3625ac0c86d67cb",
              "versionType": "git"
            },
            {
              "lessThan": "02c5f9dc2efd823e061954d564ce00bacd1bebeb",
              "status": "affected",
              "version": "335b48d980f631fbc5b233cbb3625ac0c86d67cb",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "net/rds/tcp.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "4.7"
            },
            {
              "lessThan": "4.7",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.12.*",
              "status": "unaffected",
              "version": "6.12.111",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.18.*",
              "status": "unaffected",
              "version": "6.18.53",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "7.2.*",
              "status": "unaffected",
              "version": "7.2.7",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "7.3-rc2",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.12.111",
                  "versionStartIncluding": "4.7",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.18.53",
                  "versionStartIncluding": "4.7",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "7.2.7",
                  "versionStartIncluding": "4.7",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "7.3-rc2",
                  "versionStartIncluding": "4.7",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/rds: acquire RDS_IN_XMIT in rds_tcp_reset_callbacks()\n\nrds_tcp_reset_callbacks() quiesces the transmit path by setting the\npath state to RDS_CONN_RESETTING and then waiting for RDS_IN_XMIT to\nbe sampled clear before swapping the underlying socket and calling\nrds_send_path_reset().\n\nSampling the bit clear is not the same as owning it: rds_send_xmit()\ncan re-acquire RDS_IN_XMIT right after the wait_event() returns.  Its\nstate recheck after taking the lock is a store-buffering pattern (the\nresetter writes the state and reads the bit, the sender writes the\nbit and reads the state) and acquire_in_xmit() is only an acquire\noperation, so on weakly ordered architectures both sides can miss\neach other\u0027s write and the transmit path then runs concurrently with\nrds_send_path_reset() rewriting cp_xmit_* state - which is exactly\nwhat the comment above rds_send_path_reset() tells its callers to\nprevent.\n\nTake the lock instead, hold it across the socket swap and\nrds_send_path_reset(), and release it with a wake-up at the end.  The\nlock-ordering constraint documented above the wait still holds: the\nlock is acquired before lock_sock(), so a sender inside tcp_sendmsg()\ncan never be waited on while we hold the socket lock.\n\nTwo details of the old code go away with the same change:\n\n - t_sock is now read only after the lock is acquired.  The old code\n   cached it before waiting; the teardown in rds_conn_shutdown()\n   releases that socket and clears t_sock, so a pointer cached before\n   the wait can be stale by the time the accept path resumes.  Reading\n   it under RDS_IN_XMIT is what makes the exclusion complete once the\n   teardown owns the same lock, which the next patch arranges; until\n   then the teardown still only samples the bit, and the two paths\n   remain as exposed to each other as they are today.\n\n - The old !osock early path called rds_send_path_reset() with no\n   serialization at all.  It now runs under the lock like the normal\n   path.  The conditional RDS_CONN_RESETTING transition of the\n   previous patch happens before the socket check either way: a path\n   found without a socket is either still connecting (its reconnect\n   worker blocked on t_conn_path_lock) and legitimately goes\n   RESETTING -\u003e UP on the new socket, or it has been torn down\n   meanwhile and is dropped.\n\nThe in-function comment describing the old wait-based quiesce is\nrewritten to describe the lock-based one, and the stale block comment\nabove the function (which still described a return value and an\nincomplete list of t_sock writers) is refreshed to name all four\nwriters - the connect, accept, teardown and swap paths - and what\nserializes each of them."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "baseScore": 8.1,
            "baseSeverity": "HIGH",
            "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
            "version": "3.1"
          },
          "scenarios": [
            {
              "lang": "en",
              "value": "AV:N - rds_tcp_reset_callbacks() runs when a remote peer\u0027s TCP SYN to the RDS/TCP listener is accepted by rds_tcp_accept_one() while the local path already has t_sock set (the duelling-SYN case). The peer\u0027s routable TCP connection is what sets off the unsynchronized socket swap and rds_send_path_reset().\nAC:H - The attacker must win a narrow store-buffering race between the resetter\u0027s test_bit(RDS_IN_XMIT) and rds_send_xmit()\u0027s acquire_in_xmit()/state recheck, which only fails on weakly ordered CPUs. It also needs a duelling SYN that arrives while the local path is still CONNECTING, which the attacker cannot fully control.\nPR:N - The RDS/TCP listener accepts incoming connections with no authentication. The accept path through rds_tcp_accept_one() into rds_tcp_reset_callbacks() needs only a reachable IP address and TCP port.\nUI:N - No local user action is needed. The reset path runs from the listen socket\u0027s data_ready callback and accept worker, and rds_send_xmit() is driven by the send worker or by pongs to peer pings.\nS:U - The corruption stays inside kernel memory under a single security authority. Crossing no VM or hardware isolation boundary.\nC:H - rds_send_path_reset() puts cp_xmit_rm and zeroes the cp_xmit_* offsets while a concurrent rds_send_xmit() still dereferences that rds_message. This is a use-after-free, and a stale osock cached before the wait can be released twice. Reclaiming the freed object could leak kernel memory.\nI:H - The use-after-free of the rds_message and of the stale socket, plus the torn cp_xmit_* transmit state, corrupt kernel heap objects that could be reclaimed and used for controlled writes.\nA:H - A sender using a freed cp_xmit_rm, or a double sock_release() of the stale osock, will oops or panic the kernel."
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-09-25T14:42:01.245Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/d625112564c3e980e02504270222b49b82690cee"
        },
        {
          "url": "https://git.kernel.org/stable/c/8e4c3b7844c906c7097b4cfedd9dd1f48c9a6a92"
        },
        {
          "url": "https://git.kernel.org/stable/c/062d9e008c67289e8e1b221ecdd8f9d60566d012"
        },
        {
          "url": "https://git.kernel.org/stable/c/02c5f9dc2efd823e061954d564ce00bacd1bebeb"
        }
      ],
      "title": "net/rds: acquire RDS_IN_XMIT in rds_tcp_reset_callbacks()",
      "x_generator": {
        "engine": "bippy-1.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2026-98070",
    "datePublished": "2026-09-25T10:24:11.481Z",
    "dateReserved": "2026-09-25T10:19:56.074Z",
    "dateUpdated": "2026-09-25T14:42:01.245Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2",
  "vulnerability-lookup:meta": {
    "epss": {
      "cve": "CVE-2026-98070",
      "date": "2026-09-26",
      "epss": "0.00422",
      "percentile": "0.3403"
    },
    "nvd": {
      "cve": {
        "affected": [
          {
            "affectedData": [
              {
                "defaultStatus": "unaffected",
                "product": "Linux",
                "programFiles": [
                  "net/rds/tcp.c"
                ],
                "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
                "vendor": "Linux",
                "versions": [
                  {
                    "lessThan": "d625112564c3e980e02504270222b49b82690cee",
                    "status": "affected",
                    "version": "335b48d980f631fbc5b233cbb3625ac0c86d67cb",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "8e4c3b7844c906c7097b4cfedd9dd1f48c9a6a92",
                    "status": "affected",
                    "version": "335b48d980f631fbc5b233cbb3625ac0c86d67cb",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "062d9e008c67289e8e1b221ecdd8f9d60566d012",
                    "status": "affected",
                    "version": "335b48d980f631fbc5b233cbb3625ac0c86d67cb",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "02c5f9dc2efd823e061954d564ce00bacd1bebeb",
                    "status": "affected",
                    "version": "335b48d980f631fbc5b233cbb3625ac0c86d67cb",
                    "versionType": "git"
                  }
                ]
              },
              {
                "defaultStatus": "affected",
                "product": "Linux",
                "programFiles": [
                  "net/rds/tcp.c"
                ],
                "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
                "vendor": "Linux",
                "versions": [
                  {
                    "status": "affected",
                    "version": "4.7"
                  },
                  {
                    "lessThan": "4.7",
                    "status": "unaffected",
                    "version": "0",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "6.12.*",
                    "status": "unaffected",
                    "version": "6.12.111",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "6.18.*",
                    "status": "unaffected",
                    "version": "6.18.53",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "7.2.*",
                    "status": "unaffected",
                    "version": "7.2.7",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "*",
                    "status": "unaffected",
                    "version": "7.3-rc2",
                    "versionType": "original_commit_for_fix"
                  }
                ]
              }
            ],
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
          }
        ],
        "cveTags": [],
        "descriptions": [
          {
            "lang": "en",
            "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/rds: acquire RDS_IN_XMIT in rds_tcp_reset_callbacks()\n\nrds_tcp_reset_callbacks() quiesces the transmit path by setting the\npath state to RDS_CONN_RESETTING and then waiting for RDS_IN_XMIT to\nbe sampled clear before swapping the underlying socket and calling\nrds_send_path_reset().\n\nSampling the bit clear is not the same as owning it: rds_send_xmit()\ncan re-acquire RDS_IN_XMIT right after the wait_event() returns.  Its\nstate recheck after taking the lock is a store-buffering pattern (the\nresetter writes the state and reads the bit, the sender writes the\nbit and reads the state) and acquire_in_xmit() is only an acquire\noperation, so on weakly ordered architectures both sides can miss\neach other\u0027s write and the transmit path then runs concurrently with\nrds_send_path_reset() rewriting cp_xmit_* state - which is exactly\nwhat the comment above rds_send_path_reset() tells its callers to\nprevent.\n\nTake the lock instead, hold it across the socket swap and\nrds_send_path_reset(), and release it with a wake-up at the end.  The\nlock-ordering constraint documented above the wait still holds: the\nlock is acquired before lock_sock(), so a sender inside tcp_sendmsg()\ncan never be waited on while we hold the socket lock.\n\nTwo details of the old code go away with the same change:\n\n - t_sock is now read only after the lock is acquired.  The old code\n   cached it before waiting; the teardown in rds_conn_shutdown()\n   releases that socket and clears t_sock, so a pointer cached before\n   the wait can be stale by the time the accept path resumes.  Reading\n   it under RDS_IN_XMIT is what makes the exclusion complete once the\n   teardown owns the same lock, which the next patch arranges; until\n   then the teardown still only samples the bit, and the two paths\n   remain as exposed to each other as they are today.\n\n - The old !osock early path called rds_send_path_reset() with no\n   serialization at all.  It now runs under the lock like the normal\n   path.  The conditional RDS_CONN_RESETTING transition of the\n   previous patch happens before the socket check either way: a path\n   found without a socket is either still connecting (its reconnect\n   worker blocked on t_conn_path_lock) and legitimately goes\n   RESETTING -\u003e UP on the new socket, or it has been torn down\n   meanwhile and is dropped.\n\nThe in-function comment describing the old wait-based quiesce is\nrewritten to describe the lock-based one, and the stale block comment\nabove the function (which still described a return value and an\nincomplete list of t_sock writers) is refreshed to name all four\nwriters - the connect, accept, teardown and swap paths - and what\nserializes each of them."
          }
        ],
        "id": "CVE-2026-98070",
        "lastModified": "2026-09-25T15:18:05.427",
        "metrics": {
          "cvssMetricV31": [
            {
              "cvssData": {
                "attackComplexity": "HIGH",
                "attackVector": "NETWORK",
                "availabilityImpact": "HIGH",
                "baseScore": 8.1,
                "baseSeverity": "HIGH",
                "confidentialityImpact": "HIGH",
                "integrityImpact": "HIGH",
                "privilegesRequired": "NONE",
                "scope": "UNCHANGED",
                "userInteraction": "NONE",
                "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
                "version": "3.1"
              },
              "exploitabilityScore": 2.2,
              "impactScore": 5.9,
              "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
              "type": "Secondary"
            }
          ]
        },
        "published": "2026-09-25T11:17:36.193",
        "references": [
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "url": "https://git.kernel.org/stable/c/02c5f9dc2efd823e061954d564ce00bacd1bebeb"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "url": "https://git.kernel.org/stable/c/062d9e008c67289e8e1b221ecdd8f9d60566d012"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "url": "https://git.kernel.org/stable/c/8e4c3b7844c906c7097b4cfedd9dd1f48c9a6a92"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "url": "https://git.kernel.org/stable/c/d625112564c3e980e02504270222b49b82690cee"
          }
        ],
        "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "vulnStatus": "Received"
      }
    }
  }
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

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.



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.