{"api_version":"1","generated_at":"2026-09-25T22:32:30+00:00","cve":"CVE-2026-98070","urls":{"html":"https://cve.report/CVE-2026-98070","api":"https://cve.report/api/cve/CVE-2026-98070.json","docs":"https://cve.report/api","cve_org":"https://www.cve.org/CVERecord?id=CVE-2026-98070","nvd":"https://nvd.nist.gov/vuln/detail/CVE-2026-98070"},"summary":{"title":"net/rds: acquire RDS_IN_XMIT in rds_tcp_reset_callbacks()","description":"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's 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 -> 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.","state":"PUBLISHED","assigner":"Linux","published_at":"2026-09-25 11:17:36","updated_at":"2026-09-25 15:18:05"},"problem_types":[],"metrics":[{"version":"3.1","source":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","type":"Secondary","score":"8.1","severity":"HIGH","vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H","data":{"version":"3.1","vectorString":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H","baseScore":8.1,"baseSeverity":"HIGH","attackVector":"NETWORK","attackComplexity":"HIGH","privilegesRequired":"NONE","userInteraction":"NONE","scope":"UNCHANGED","confidentialityImpact":"HIGH","integrityImpact":"HIGH","availabilityImpact":"HIGH"}},{"version":"3.1","source":"CNA","type":"DECLARED","score":"8.1","severity":"HIGH","vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H","data":{"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"}}],"references":[{"url":"https://git.kernel.org/stable/c/062d9e008c67289e8e1b221ecdd8f9d60566d012","name":"https://git.kernel.org/stable/c/062d9e008c67289e8e1b221ecdd8f9d60566d012","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/8e4c3b7844c906c7097b4cfedd9dd1f48c9a6a92","name":"https://git.kernel.org/stable/c/8e4c3b7844c906c7097b4cfedd9dd1f48c9a6a92","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/02c5f9dc2efd823e061954d564ce00bacd1bebeb","name":"https://git.kernel.org/stable/c/02c5f9dc2efd823e061954d564ce00bacd1bebeb","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/d625112564c3e980e02504270222b49b82690cee","name":"https://git.kernel.org/stable/c/d625112564c3e980e02504270222b49b82690cee","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-98070","name":"CVE Program record","refsource":"CVE.ORG","tags":["canonical"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-98070","name":"NVD vulnerability detail","refsource":"NVD","tags":["canonical","analysis"]}],"affected":[{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 335b48d980f631fbc5b233cbb3625ac0c86d67cb d625112564c3e980e02504270222b49b82690cee git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 335b48d980f631fbc5b233cbb3625ac0c86d67cb 8e4c3b7844c906c7097b4cfedd9dd1f48c9a6a92 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 335b48d980f631fbc5b233cbb3625ac0c86d67cb 062d9e008c67289e8e1b221ecdd8f9d60566d012 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 335b48d980f631fbc5b233cbb3625ac0c86d67cb 02c5f9dc2efd823e061954d564ce00bacd1bebeb git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 4.7","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 4.7 semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.12.111 6.12.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.18.53 6.18.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 7.2.7 7.2.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 7.3-rc2 * original_commit_for_fix","platforms":[]}],"timeline":[],"solutions":[],"workarounds":[],"exploits":[],"credits":[],"nvd_cpes":[],"vendor_comments":[],"enrichments":{"kev":null,"epss":null,"legacy_qids":[]},"source_records":{"cve_program":{"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's 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 -> 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's 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's 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's test_bit(RDS_IN_XMIT) and rds_send_xmit()'s 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's 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"},"nvd":{"publishedDate":"2026-09-25 11:17:36","lastModifiedDate":"2026-09-25 15:18:05","problem_types":[],"metrics":{"cvssMetricV31":[{"source":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","type":"Secondary","cvssData":{"version":"3.1","vectorString":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H","baseScore":8.1,"baseSeverity":"HIGH","attackVector":"NETWORK","attackComplexity":"HIGH","privilegesRequired":"NONE","userInteraction":"NONE","scope":"UNCHANGED","confidentialityImpact":"HIGH","integrityImpact":"HIGH","availabilityImpact":"HIGH"},"exploitabilityScore":2.2,"impactScore":5.9}]},"configurations":[]},"legacy_mitre":{"record":{"CveYear":"2026","CveId":"98070","Ordinal":"1","Title":"net/rds: acquire RDS_IN_XMIT in rds_tcp_reset_callbacks()","CVE":"CVE-2026-98070","Year":"2026"},"notes":[{"CveYear":"2026","CveId":"98070","Ordinal":"1","NoteData":"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's 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 -> 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.","Type":"Description","Title":"net/rds: acquire RDS_IN_XMIT in rds_tcp_reset_callbacks()"}]}}}