FKIE_CVE-2026-98068
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/connection.c",
"net/rds/tcp.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "f777c602d3e15d3414b53f760147687bd56b03f2",
"status": "affected",
"version": "e97656d03ca0cea888a0b9d382abce8233771f31",
"versionType": "git"
},
{
"lessThan": "7cb11257aa3e5ef0bedfd5d55ac60bb00347aa97",
"status": "affected",
"version": "e97656d03ca0cea888a0b9d382abce8233771f31",
"versionType": "git"
},
{
"lessThan": "4980ce260205001d582a7b3cb5eab29877777fbc",
"status": "affected",
"version": "e97656d03ca0cea888a0b9d382abce8233771f31",
"versionType": "git"
},
{
"lessThan": "0ec75c69918b7f6a1a5e3fb6442925246a9ec86b",
"status": "affected",
"version": "e97656d03ca0cea888a0b9d382abce8233771f31",
"versionType": "git"
},
{
"lessThan": "bd1cb197a07111ca8d4f4c21411c56a3c85a9797",
"status": "affected",
"version": "e97656d03ca0cea888a0b9d382abce8233771f31",
"versionType": "git"
},
{
"lessThan": "4cb9b6d3d31a2dbaa5469981c2c4c03e9acc7aca",
"status": "affected",
"version": "e97656d03ca0cea888a0b9d382abce8233771f31",
"versionType": "git"
},
{
"lessThan": "2941561395066be856a53626d4ca973dd9c982b2",
"status": "affected",
"version": "e97656d03ca0cea888a0b9d382abce8233771f31",
"versionType": "git"
},
{
"lessThan": "260c6308fe2e19ad519389d44d582e292aecc3af",
"status": "affected",
"version": "e97656d03ca0cea888a0b9d382abce8233771f31",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"net/rds/connection.c",
"net/rds/tcp.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "4.12"
},
{
"lessThan": "4.12",
"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: don\u0027t let rds_conn_shutdown() consume a concurrent drop\n\nrds_conn_shutdown() finishes by moving the path from\nRDS_CONN_DISCONNECTING to RDS_CONN_DOWN, and also accepts\nRDS_CONN_ERROR as the starting state of that final transition, so that\na FIN processed in softirq context during the teardown does not derail\nthe shutdown into a noisy error path.\n\nBut consuming that RDS_CONN_ERROR also consumes the shutdown pass that\ncame with it: rds_conn_path_drop() sets RDS_CONN_ERROR and then queues\ncp_down_w, and a pass that starts on a path already in RDS_CONN_DOWN\nis a no-op. For the FIN case that is harmless - the socket the FIN\narrived on is the very socket the teardown just released. It is not\nharmless for a dropper that attached something to the path first.\n\nrds_tcp_accept_one() is such a dropper. Its path claim in\nrds_tcp_accept_one_path() transitions RDS_CONN_DOWN -\u003e\nRDS_CONN_CONNECTING, and a concurrent drop - a FIN on a previous\nsocket in softirq context, an administrative reset - can put the path\ninto RDS_CONN_ERROR between that claim and the state check that\nfollows, which accepts RDS_CONN_ERROR. The accept then installs the\nfreshly accepted socket with rds_tcp_set_callbacks() while the queued\nteardown - which sampled tc-\u003et_sock before this socket existed - is\nstill running. rds_connect_path_complete() fails its transition to\nRDS_CONN_UP and drops the path again, queueing the pass that should\nreap the socket it just installed. If the in-flight shutdown\u0027s final\ntransition consumes that drop\u0027s RDS_CONN_ERROR, the queued pass finds\nthe path in RDS_CONN_DOWN and does nothing. The installed socket is\nnever torn down: it sits established with its callbacks armed and its\nrds_tcp_connection on rds_tcp_tc_list, the peer sees a connection that\nnothing ever reads, and the path is wedged in RDS_CONN_DOWN until some\nlater event drops it again. Reproduced with widened race windows as\nan ever-growing receive queue on a socket owned by a path stuck in\nRDS_CONN_DOWN, with the peer\u0027s send path wedged behind it.\n\nMake the final transition only DISCONNECTING -\u003e DOWN. If it fails\nbecause the path is in RDS_CONN_ERROR, a drop raced the teardown:\ncancel the reconnect timer and clear RDS_RECONNECT_PENDING - the one\npiece of the skipped tail that must not be left behind - and return,\nletting the pass the drop queued finish the job: it tears down\nwhatever attached to the path in the meantime, completes the\ntransition to RDS_CONN_DOWN, and re-arms the reconnect from its own\ntail.\n\nThe timer quiesce in that branch matters because the racing drop does\nnot always queue that pass: rds_conn_path_drop() returns without\nqueueing when a destroy is pending - exactly the situation during a\nnetns teardown or module unload, when a FIN on the dying socket is\nprocessed while rds_conn_path_destroy() flushes cp_down_w. If the\nflushed pass is the one that takes this return, no later pass exists,\nand rds_conn_path_destroy() would find cp_conn_w still armed\n(WARN_ON) and then free a path whose reconnect timer can still fire.\nWith the cancel in the branch, every exit of a shutdown pass leaves\nthe timer quiesced no matter which pass completes the transition.\n\nThe FIN case keeps making progress, one pass later and still without\nnoisy logging. Any other state keeps today\u0027s rds_conn_path_error()\nhandling; no current cp_state writer can leave a DISCONNECTING path\nin anything but RDS_CONN_ERROR (every other writer is a cmpxchg from\na non-DISCONNECTING state), so that branch is defensive.\n\nOn kernels without the preceding patches the same hazard exists with\nthe sample-based quiesce; the fix applies there equally."
}
],
"id": "CVE-2026-98068",
"lastModified": "2026-10-19T10:18:01.687",
"metrics": {},
"published": "2026-09-25T11:17:35.903",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/0ec75c69918b7f6a1a5e3fb6442925246a9ec86b"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/260c6308fe2e19ad519389d44d582e292aecc3af"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/2941561395066be856a53626d4ca973dd9c982b2"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/4980ce260205001d582a7b3cb5eab29877777fbc"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/4cb9b6d3d31a2dbaa5469981c2c4c03e9acc7aca"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/7cb11257aa3e5ef0bedfd5d55ac60bb00347aa97"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/bd1cb197a07111ca8d4f4c21411c56a3c85a9797"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/f777c602d3e15d3414b53f760147687bd56b03f2"
}
],
"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.