CVE-2026-43226

net/rds: No shortcut out of RDS_CONN_ERROR

High · published May 6, 2026

CVSS v3.1
7.5
EPSS
1%
Percentile
53.2
In the wild
Unconfirmed
What it is

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

net/rds: No shortcut out of RDS_CONN_ERROR

RDS connections carry a state "rds_conn_path::cp_state"

and transitions from one state to another and are conditional

upon an expected state: "rds_conn_path_transition."

There is one exception to this conditionality, which is

"RDS_CONN_ERROR" that can be enforced by "rds_conn_path_drop"

regardless of what state the condition is currently in.

But as soon as a connection enters state "RDS_CONN_ERROR",

the connection handling code expects it to go through the

shutdown-path.

The RDS/TCP multipath changes added a shortcut out of

"RDS_CONN_ERROR" straight back to "RDS_CONN_CONNECTING"

via "rds_tcp_accept_one_path" (e.g. after "rds_tcp_state_change").

A subsequent "rds_tcp_reset_callbacks" can then transition

the state to "RDS_CONN_RESETTING" with a shutdown-worker queued.

That'll trip up "rds_conn_init_shutdown", which was

never adjusted to handle "RDS_CONN_RESETTING" and subsequently

drops the connection with the dreaded "DR_INV_CONN_STATE",

which leaves "RDS_SHUTDOWN_WORK_QUEUED" on forever.

So we do two things here:

a) Don't shortcut "RDS_CONN_ERROR", but take the longer

path through the shutdown code.

b) Add "RDS_CONN_RESETTING" to the expected states in

"rds_conn_init_shutdown" so that we won't error out

and get stuck, if we ever hit weird state transitions

like this again."

The record
Technical detail
CVSS v3.1
7.5 · HIGH
Vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
CVSS v4.0
Not supplied
EPSS
0.00716 · 53.2th percentile
Published
2026-05-06T11:28Z
EPSS history
Timeline
  • 06 MAY 11:28Z
    net/rds: No shortcut out of RDS_CONN_ERROR
    cvelistv5