CVE-2026-98068

Status: UPDATED  |  Advisory ID: CVE-2026-98068

Key Details

Affected Products, Subsystems & Sectors

What to Know

In the Linux kernel, the following vulnerability has been resolved:

net/rds: don't let rds_conn_shutdown() consume a concurrent drop

rds_conn_shutdown() finishes by moving the path from

RDS_CONN_DISCONNECTING to RDS_CONN_DOWN, and also accepts

RDS_CONN_ERROR as the starting state of that final transition, so that

a FIN processed in softirq context during the teardown does not derail

the shutdown into a noisy error path.

But consuming that RDS_CONN_ERROR also consumes the shutdown pass that

came with it: rds_conn_path_drop() sets RDS_CONN_ERROR and then queues

cp_down_w, and a pass that starts on a path already in RDS_CONN_DOWN

is a no-op. For the FIN case that is harmless - the socket the FIN

arrived on is the very socket the teardown just released. It is not

harmless for a dropper that attached something to the path first.

rds_tcp_accept_one() is such a dropper. Its path claim in

rds_tcp_accept_one_path() transitions RDS_CONN_DOWN ->

RDS_CONN_CONNECTING, and a concurrent drop - a FIN on a previous

socket in softirq context, an administrative reset - can put the path

into RDS_CONN_ERROR between that claim and the state check that

follows, which accepts RDS_CONN_ERROR. The accept then installs the

freshly accepted socket with rds_tcp_set_callbacks() while the queued

teardown - which sampled tc->t_sock before this socket existed - is

still running. rds_connect_path_complete() fails its transition to

RDS_CONN_UP and drops the path again, queueing the pass that should

reap the socket it just installed. If the in-flight shutdown's final

transition consumes that drop's RDS_CONN_ERROR, the queued pass finds

the path in RDS_CONN_DOWN and does nothing. The installed socket is

never torn down: it sits established with its callbacks armed and its

rds_tcp_connection on rds_tcp_tc_list, the peer sees a connection that

nothing ever reads, and the path is wedged in RDS_CONN_DOWN until some

later event drops it again. Reproduced with widened race windows as

an ever-growing receive queue on a socket owned by a path stuck in

RDS_CONN_DOWN, with the peer's send path wedged behind it.

Make the final transition only DISCONNECTING -> DOWN. If it fails

because the path is in RDS_CONN_ERROR, a drop raced the teardown:

cancel the reconnect timer and clear RDS_RECONNECT_PENDING - the one

piece of the skipped tail that must not be left behind - and return,

letting the pass the drop queued finish the job: it tears down

whatever attached to the path in the meantime, completes the

transition to RDS_CONN_DOWN, and re-arms the reconnect from its own

tail.

The timer quiesce in that branch matters because the racing drop does

not always queue that pass: rds_conn_path_drop() returns without

queueing when a destroy is pending - exactly the situation during a

netns teardown or module unload, when a FIN on the dying socket is

processed while rds_conn_path_destroy() flushes cp_down_w. If the

flushed pass is the one that takes this return, no later pass exists,

and rds_conn_path_destroy() would find cp_conn_w still armed

(WARN_ON) and then free a path whose reconnect timer can still fire.

With the cancel in the branch, every exit of a shutdown pass leaves

the timer quiesced no matter which pass completes the transition.

The FIN case keeps making progress, one pass later and still without

noisy logging. Any other state keeps today's rds_conn_path_error()

handling; no current cp_state writer can leave a DISCONNECTING path

in anything but RDS_CONN_ERROR (every other writer is a cmpxchg from

a non-DISCONNECTING state), so that branch is defensive.

On kernels without the preceding patches the same hazard exists with

the sample-based quiesce; the fix applies there equally. (NVD)

What to Do

Monitor Linux's web page for any future patch releases.

References