In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
net\/rds: don’t let rds_conn_shutdown() consume a concurrent drop<\/p>\n
rds_conn_shutdown() finishes by moving the path from
\nRDS_CONN_DISCONNECTING to RDS_CONN_DOWN, and also accepts
\nRDS_CONN_ERROR as the starting state of that final transition, so that
\na FIN processed in softirq context during the teardown does not derail
\nthe shutdown into a noisy error path.<\/p>\n
But consuming that RDS_CONN_ERROR also consumes the shutdown pass that
\ncame with it: rds_conn_path_drop() sets RDS_CONN_ERROR and then queues
\ncp_down_w, and a pass that starts on a path already in RDS_CONN_DOWN
\nis a no-op. For the FIN case that is harmless – the socket the FIN
\narrived on is the very socket the teardown just released. It is not
\nharmless for a dropper that attached something to the path first.<\/p>\n
rds_tcp_accept_one() is such a dropper. Its path claim in
\nrds_tcp_accept_one_path() transitions RDS_CONN_DOWN ->
\nRDS_CONN_CONNECTING, and a concurrent drop – a FIN on a previous
\nsocket in softirq context, an administrative reset – can put the path
\ninto RDS_CONN_ERROR between that claim and the state check that
\nfollows, which accepts RDS_CONN_ERROR. The accept then installs the
\nfreshly accepted socket with rds_tcp_set_callbacks() while the queued
\nteardown – which sampled tc->t_sock before this socket existed – is
\nstill running. rds_connect_path_complete() fails its transition to
\nRDS_CONN_UP and drops the path again, queueing the pass that should
\nreap the socket it just installed. If the in-flight shutdown’s final
\ntransition consumes that drop’s RDS_CONN_ERROR, the queued pass finds
\nthe path in RDS_CONN_DOWN and does nothing. The installed socket is
\nnever torn down: it sits established with its callbacks armed and its
\nrds_tcp_connection on rds_tcp_tc_list, the peer sees a connection that
\nnothing ever reads, and the path is wedged in RDS_CONN_DOWN until some
\nlater event drops it again. Reproduced with widened race windows as
\nan ever-growing receive queue on a socket owned by a path stuck in
\nRDS_CONN_DOWN, with the peer’s send path wedged behind it.<\/p>\n
Make the final transition only DISCONNECTING -> DOWN. If it fails
\nbecause the path is in RDS_CONN_ERROR, a drop raced the teardown:
\ncancel the reconnect timer and clear RDS_RECONNECT_PENDING – the one
\npiece of the skipped tail that must not be left behind – and return,
\nletting the pass the drop queued finish the job: it tears down
\nwhatever attached to the path in the meantime, completes the
\ntransition to RDS_CONN_DOWN, and re-arms the reconnect from its own
\ntail.<\/p>\n
The timer quiesce in that branch matters because the racing drop does
\nnot always queue that pass: rds_conn_path_drop() returns without
\nqueueing when a destroy is pending – exactly the situation during a
\nnetns teardown or module unload, when a FIN on the dying socket is
\nprocessed while rds_conn_path_destroy() flushes cp_down_w. If the
\nflushed pass is the one that takes this return, no later pass exists,
\nand rds_conn_path_destroy() would find cp_conn_w still armed
\n(WARN_ON) and then free a path whose reconnect timer can still fire.
\nWith the cancel in the branch, every exit of a shutdown pass leaves
\nthe timer quiesced no matter which pass completes the transition.<\/p>\n
The FIN case keeps making progress, one pass later and still without
\nnoisy logging. Any other state keeps today’s rds_conn_path_error()
\nhandling; no current cp_state writer can leave a DISCONNECTING path
\nin anything but RDS_CONN_ERROR (every other writer is a cmpxchg from
\na non-DISCONNECTING state), so that branch is defensive.<\/p>\n
On kernels without the preceding patches the same hazard exists with
\nthe sample-based quiesce; the fix applies there equally.<\/p>\n","protected":false},"excerpt":{"rendered":"
In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
net\/rds: don’t let rds_conn_shutdown() consume a concurrent drop<\/p>\n
rds_conn_shutdown() finishes by moving the path from
\nRDS_CONN_DIS<\/p>\n","protected":false},"template":"","meta":[],"categories":[],"tags":[],"class_list":["post-29223","vuln","type-vuln","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln\/29223","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln"}],"about":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/types\/vuln"}],"wp:attachment":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=29223"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=29223"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=29223"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}