Homepage

Incomplete Internal State Distinction The advisory has been revoked - it doesn't affect any version of package perf6.18-debuginfo  (opens in a new tab)

Threat Intelligence

EPSS
0.07% (21st percentile)

Do your applications use this vulnerable package?

In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.

Test your applications
  • Snyk IDSNYK-AMZN2023-PERF618DEBUGINFO-16740701
  • published18 May 2026
  • disclosed6 May 2026
Report a new vulnerability Found a mistake?

Introduced: 6 May 2026

NewCVE-2026-43226  (opens in a new tab)
CWE-372  (opens in a new tab)

Amendment

The Amazon-Linux security team deemed this advisory irrelevant for Amazon-Linux:2023.

NVD Description

Note: Versions mentioned in the description apply only to the upstream perf6.18-debuginfo package and not the perf6.18-debuginfo package as distributed by Amazon-Linux.

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."