Description
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.
Published: 2026-09-25
Score: 8.1 High
EPSS: n/a
KEV: No
Impact: Denial of Service
Action: Apply Patch
AI Analysis

Impact

A race condition within the Linux kernel's RDS protocol has been discovered. The bug arises when the reset callback releases the transmit lock too early, allowing the send path to re-acquire the RDS_IN_XMIT flag concurrently with a reset operation. This lack of proper synchronization can allow the data structures to be accessed or modified at the same time, potentially corrupting state or causing a crash. The weakness is a classic race condition (CWE‑362) that affects kernel integrity and availability.

Affected Systems

The affected component is the Linux kernel's RDS implementation; the issue is present in all kernel versions that include the RDS module and for which the patch has not been applied. No specific version numbers are supplied in the advisory.

Risk and Exploitability

The CVSS score is not reported, and EPSS is unavailable, so the likelihood of exploitation cannot be quantified. However, because the bug resides in kernel code that can be triggered by normal RDS traffic, an attacker with sufficient privileges or the ability to generate RDS packets could potentially cause the kernel to crash or become unreachable, leading to denial of service. The vector is thus a local or remote kernel exploitation scenario that exploits a concurrency flaw. The vulnerability is not listed in the CISA KEV catalog, indicating no confirmed exploitation in the wild yet, but the bug remains a high‑impact kernel race condition.

Generated by OpenCVE AI on September 25, 2026 at 15:38 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Deploy the kernel update that contains the RDS reset path fix found in the linked patch commits
  • If a patch cannot be applied immediately, disable the RDS protocol on the machine to remove the attack surface
  • Verify that no custom kernel patches reintroduce the old lock ordering and ensure the new locking logic is in place

Generated by OpenCVE AI on September 25, 2026 at 15:38 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Fri, 25 Sep 2026 16:00:00 +0000

Type Values Removed Values Added
Weaknesses CWE-362

Fri, 25 Sep 2026 15:00:00 +0000

Type Values Removed Values Added
Metrics cvssV3_1

{'score': 8.1, 'vector': 'CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H'}

Fri, 25 Sep 2026 10:30:00 +0000

Type Values Removed Values Added
Description 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.
Title net/rds: acquire RDS_IN_XMIT in rds_tcp_reset_callbacks()
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-09-25T14:42:01.245Z

Reserved: 2026-09-25T10:19:56.074Z

Link: CVE-2026-98070

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-09-25T11:17:36.193

Modified: 2026-09-25T15:18:05.427

Link: CVE-2026-98070

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-09-25T15:45:19Z

Weaknesses
  • CWE-362

    Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')