CVE-2026-43226

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/rds: No shortcut out of RDS_CONN_ERROR<br /> <br /> RDS connections carry a state "rds_conn_path::cp_state"<br /> and transitions from one state to another and are conditional<br /> upon an expected state: "rds_conn_path_transition."<br /> <br /> There is one exception to this conditionality, which is<br /> "RDS_CONN_ERROR" that can be enforced by "rds_conn_path_drop"<br /> regardless of what state the condition is currently in.<br /> <br /> But as soon as a connection enters state "RDS_CONN_ERROR",<br /> the connection handling code expects it to go through the<br /> shutdown-path.<br /> <br /> The RDS/TCP multipath changes added a shortcut out of<br /> "RDS_CONN_ERROR" straight back to "RDS_CONN_CONNECTING"<br /> via "rds_tcp_accept_one_path" (e.g. after "rds_tcp_state_change").<br /> <br /> A subsequent "rds_tcp_reset_callbacks" can then transition<br /> the state to "RDS_CONN_RESETTING" with a shutdown-worker queued.<br /> <br /> That&amp;#39;ll trip up "rds_conn_init_shutdown", which was<br /> never adjusted to handle "RDS_CONN_RESETTING" and subsequently<br /> drops the connection with the dreaded "DR_INV_CONN_STATE",<br /> which leaves "RDS_SHUTDOWN_WORK_QUEUED" on forever.<br /> <br /> So we do two things here:<br /> <br /> a) Don&amp;#39;t shortcut "RDS_CONN_ERROR", but take the longer<br /> path through the shutdown code.<br /> <br /> b) Add "RDS_CONN_RESETTING" to the expected states in<br /> "rds_conn_init_shutdown" so that we won&amp;#39;t error out<br /> and get stuck, if we ever hit weird state transitions<br /> like this again."