FKIE_CVE-2026-98070
Vulnerability from fkie_nvd - Published: 2026-09-25 11:17 - Updated: 2026-10-19 10:18| Vendor | Product | Version |
|---|
{
"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": "670af4e4a4de5e6bb5daee3838485571a0caa5fa",
"status": "affected",
"version": "335b48d980f631fbc5b233cbb3625ac0c86d67cb",
"versionType": "git"
},
{
"lessThan": "830a2e21b200c6b6fdccc63dd3f23932bf7a894b",
"status": "affected",
"version": "335b48d980f631fbc5b233cbb3625ac0c86d67cb",
"versionType": "git"
},
{
"lessThan": "a05790cb4ff03f797d76906990b148d83f63e7a3",
"status": "affected",
"version": "335b48d980f631fbc5b233cbb3625ac0c86d67cb",
"versionType": "git"
},
{
"lessThan": "d184e6dd4b8f3c20c018595fd09795a66b46c8ef",
"status": "affected",
"version": "335b48d980f631fbc5b233cbb3625ac0c86d67cb",
"versionType": "git"
},
{
"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": "5.10.*",
"status": "unaffected",
"version": "5.10.271",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.222",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.189",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.158",
"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",
"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-10-19T10:18:02.123",
"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/670af4e4a4de5e6bb5daee3838485571a0caa5fa"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/830a2e21b200c6b6fdccc63dd3f23932bf7a894b"
},
{
"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/a05790cb4ff03f797d76906990b148d83f63e7a3"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/d184e6dd4b8f3c20c018595fd09795a66b46c8ef"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/d625112564c3e980e02504270222b49b82690cee"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Awaiting Analysis"
}
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
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.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
How durations are calculated
Following the VTEM framework (Black Hat USA 2015), time to patch starts when the vendor or a coordinator was informed, total time to patch at discovery, and disclosure to patch at public disclosure; vendor response time runs from the report to its acknowledgement. Time to exploit and time unpatched start at the earliest discovery or report, falling back to public disclosure. Unpatched time ends at the first recorded patch, or the calculation time when no patch is recorded. Exploitation to patch shows the interval between those two events; a published proof of concept is a public exploit, not exploitation.
Each result shows its source dates. A negative interval means the end event came first; when date-only inputs leave the order open, the result says so. Date-only inputs are approximate. The earliest evidence wins: KEV report dates and sightings are labelled as such. Records describing another vulnerability are listed but never calculated from, and a PoC alone does not establish exploitation. Missing patch evidence does not prove that no patch exists. Filters below change the event list only.
Loading timeline…
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.