{"id":29224,"date":"2026-09-25T20:32:11","date_gmt":"2026-09-25T12:32:11","guid":{"rendered":"https:\/\/www.54iter.cn\/?vuln=cve-2026-98069"},"modified":"2026-09-25T20:32:11","modified_gmt":"2026-09-25T12:32:11","slug":"cve-2026-98069","status":"publish","type":"vuln","link":"https:\/\/www.54iter.cn\/?vuln=cve-2026-98069","title":{"rendered":"CVE-2026-98069 &#8211; In the Linux kernel, the following vulnerability has been resolved:\n\nnet\/rds: acquire the"},"content":{"rendered":"<p>In the Linux kernel, the following vulnerability has been resolved:<\/p>\n<p>net\/rds: acquire the fastpath locks in rds_conn_shutdown()<\/p>\n<p>rds_conn_shutdown() quiesces the transmit and receive-refill paths by<br \/>\nwaiting for RDS_IN_XMIT and RDS_RECV_REFILL to be sampled clear, and<br \/>\nthen runs the transport shutdown and rds_conn_path_reset().  Sampling<br \/>\nthe bits clear is not the same as owning them: the moment after the<br \/>\nwait_event() returns, rds_send_xmit() can re-acquire RDS_IN_XMIT (or<br \/>\nrds_ib_recv_refill() can re-acquire RDS_RECV_REFILL) and run<br \/>\nconcurrently with the teardown.<\/p>\n<p>The sender does recheck the connection state after taking the lock,<br \/>\nbut that recheck is a classic store-buffering pattern: teardown writes<br \/>\nthe state and reads the bit while the sender writes the bit and reads<br \/>\nthe state.  acquire_in_xmit() is only an acquire operation, so on<br \/>\nweakly ordered architectures both sides can miss each other&#8217;s write,<br \/>\nand the transmit path then runs while the transport zeroes its rings<br \/>\n(e.g. rds_ib_ring_init()) and rds_send_path_reset() rewrites the<br \/>\ntransmit state under it.<\/p>\n<p>Oracle UEK fixed the same class of crashes &#8211; a 14-year tail of<br \/>\nBUG_ON()s in rds_ib_sub_signaled(), unexpected op-codes and NULL<br \/>\ndereferences in rds_ib_send_cqe_handler() during failover testing &#8211;<br \/>\nby making the teardown path *acquire* the fastpath bit locks instead<br \/>\nof testing them (&#8220;rds: Make sure transmit path and connection<br \/>\ntear-down does not run concurrently&#8221;).  Ownership of a single word is<br \/>\ndecided by RMW atomicity, so no cross-variable ordering is needed.<\/p>\n<p>Do the same here: take both locks before calling the transport<br \/>\nshutdown, hold them across rds_conn_path_reset(), and release them<br \/>\nexplicitly with a wake-up afterwards.  Both are released with<br \/>\nclear_bit_unlock(), so that the ring re-initialization done by the<br \/>\ntransport shutdown and the transmit state rewritten by<br \/>\nrds_send_path_reset() are ordered before either bit is seen clear by<br \/>\nthe next acquire_in_xmit() or acquire_refill().<\/p>\n<p>The fastpath users of these bits &#8211; rds_send_xmit() and<br \/>\nrds_ib_recv_refill() &#8211; are trylock style and back off while teardown<br \/>\nowns the locks, so no new lock dependency is introduced for them.<br \/>\nrds_tcp_reset_callbacks() is different: since the previous patch it<br \/>\nacquires RDS_IN_XMIT as well, and it blocks doing so, so its wait now<br \/>\nspans the teardown instead of at most one send batch.  That waiter<br \/>\nruns from rds_tcp_accept_one() on the single-threaded krdsd workqueue<br \/>\nand holds rds_tcp_accept_lock and t_conn_path_lock while it waits, so<br \/>\na duelling SYN accepted while its path is being torn down parks<br \/>\naccept processing for the duration of the teardown &#8211; for TCP bounded<br \/>\nby the (up to 5 s) drain loop in rds_tcp_conn_path_shutdown().  An IB<br \/>\npath&#8217;s drain in rds_ib_conn_path_shutdown() has no round cap, but no<br \/>\nblocking waiter either: rds_tcp_reset_callbacks() is the only blocking<br \/>\nacquirer of these bits and waits only on its own TCP path, and the<br \/>\nfastpaths are trylock-and-back-off on both transports, so a long IB<br \/>\ndrain lengthens only that path&#8217;s own quiesce.  The<br \/>\nwindow is narrow: the accept-side state check has to pass before the<br \/>\nteardown moves the path to RDS_CONN_DISCONNECTING.<\/p>\n<p>Because krdsd is a single global workqueue, everything else queued<br \/>\nthere &#8211; accept processing for other connections and network<br \/>\nnamespaces, and the flush_workqueue(rds_wq) in rds_tcp_listen_stop()<br \/>\nduring namespace teardown &#8211; waits behind the parked accept worker for<br \/>\nthat time.  It cannot deadlock, although the waits do point at each<br \/>\nother: the teardown blocks until the bit&#8217;s holder releases it, and<br \/>\nthe holder may be that krdsd accept worker.  The holder finishes<br \/>\nwithout needing anything the teardown owns: the sync cancels<br \/>\nrds_tcp_reset_callbacks() issues target cp_send_w and cp_recv_w on<br \/>\nthe path&#8217;s ordered cp_wq, whose only execution slot is occupied by<br \/>\nthe blocked cp_down_w itself, so they are pending at most and cancel<br \/>\nwithout flushing &#8211; a reliance on cp_wq being ordered that is now<br \/>\nnoted next to those cancels (on<br \/>\n&#8212;truncated&#8212;<\/p>\n","protected":false},"excerpt":{"rendered":"<p>In the Linux kernel, the following vulnerability has been resolved:<\/p>\n<p>net\/rds: acquire the fastpath locks in rds_conn_shutdown()<\/p>\n<p>rds_conn_shutdown() quiesces the transmit and receive-refill paths by<br \/>\nw<\/p>\n","protected":false},"template":"","meta":[],"categories":[],"tags":[],"class_list":["post-29224","vuln","type-vuln","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln\/29224","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=29224"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=29224"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=29224"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}