CVE-2026-98068

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.