CVE-2026-98070
Awaiting Analysis Awaiting Analysis - Queue

Race Condition in Linux Kernel RDS TCP Connection Handling

Vulnerability report for CVE-2026-98070, including description, CVSS score, EPSS score, affected products, exploitability, helpful resources, and attack-flow context.

Publication date: 2026-09-25

Last updated on: 2026-10-03

Assigner: kernel.org

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.

CVSS Scores

EPSS Scores

Probability:
Percentile:

Meta Information

Published
2026-09-25
Last Modified
2026-10-03
Generated
2026-10-15
AI Q&A
2026-09-25
EPSS Evaluated
2026-10-14
NVD
EUVD

Affected Vendors & Products

Showing 1 associated CPE
Vendor Product Version / Range
linux_kernel linux_kernel *

Helpful Resources

Exploitability

CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN

Attack-Flow Graph

AI Quick Actions

Instant insights powered by AI
Executive Summary

This vulnerability in the Linux kernel involves a race condition in the RDS (Reliable Datagram Sockets) TCP reset handling. The issue occurs when rds_tcp_reset_callbacks() attempts to quiesce the transmit path by waiting for RDS_IN_XMIT to clear, but this method is unreliable due to weak memory ordering on some architectures. The sender can re-acquire RDS_IN_XMIT after the wait, causing concurrent execution with rds_send_path_reset(), which corrupts cp_xmit_* state.

Detection Guidance

This vulnerability is specific to the Linux kernel's RDS (Reliable Datagram Sockets) TCP reset handling. Detection requires checking for kernel versions affected by this issue and monitoring for related crashes or corruption in RDS operations. No direct commands are provided in the context, but you can inspect kernel logs for RDS-related errors or crashes.

Impact Analysis

This vulnerability could lead to memory corruption or system crashes in systems using the Linux kernel with RDS over TCP. Attackers might exploit it to cause denial-of-service conditions or potentially execute arbitrary code with kernel privileges.

Compliance Impact

This vulnerability affects compliance with standards like GDPR and HIPAA by potentially enabling unauthorized data access or disruption of network services. The flaw allows concurrent execution of transmit and reset operations in the Linux kernel's RDS protocol, which could lead to data corruption, unauthorized information disclosure, or service disruption. Such issues may violate confidentiality and integrity requirements in GDPR and HIPAA.

Mitigation Strategies

Apply the latest kernel patches that address this issue. Since the vulnerability involves race conditions in RDS TCP reset handling, updating to a patched kernel version is the primary mitigation. Monitor vendor advisories for kernel updates addressing CVE-2026-98070.

Chat Assistant

Ask questions about this CVE
Hi! I’m here to help you understand CVE-2026-98070. Ask me anything about the vulnerability, its impact, or mitigation strategies.
0/70

EPSS Chart