GHSA-MJJ8-GM8F-325H

Vulnerability from github – Published: 2026-05-06 12:30 – Updated: 2026-05-08 15:31
VLAI
Details

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

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-43226"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-06T12:16:42Z",
    "severity": "HIGH"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/rds: No shortcut out of RDS_CONN_ERROR\n\nRDS connections carry a state \"rds_conn_path::cp_state\"\nand transitions from one state to another and are conditional\nupon an expected state: \"rds_conn_path_transition.\"\n\nThere is one exception to this conditionality, which is\n\"RDS_CONN_ERROR\" that can be enforced by \"rds_conn_path_drop\"\nregardless of what state the condition is currently in.\n\nBut as soon as a connection enters state \"RDS_CONN_ERROR\",\nthe connection handling code expects it to go through the\nshutdown-path.\n\nThe RDS/TCP multipath changes added a shortcut out of\n\"RDS_CONN_ERROR\" straight back to \"RDS_CONN_CONNECTING\"\nvia \"rds_tcp_accept_one_path\" (e.g. after \"rds_tcp_state_change\").\n\nA subsequent \"rds_tcp_reset_callbacks\" can then transition\nthe state to \"RDS_CONN_RESETTING\" with a shutdown-worker queued.\n\nThat\u0027ll trip up \"rds_conn_init_shutdown\", which was\nnever adjusted to handle \"RDS_CONN_RESETTING\" and subsequently\ndrops the connection with the dreaded \"DR_INV_CONN_STATE\",\nwhich leaves \"RDS_SHUTDOWN_WORK_QUEUED\" on forever.\n\nSo we do two things here:\n\na) Don\u0027t shortcut \"RDS_CONN_ERROR\", but take the longer\n   path through the shutdown code.\n\nb) Add \"RDS_CONN_RESETTING\" to the expected states in\n  \"rds_conn_init_shutdown\" so that we won\u0027t error out\n  and get stuck, if we ever hit weird state transitions\n  like this again.\"",
  "id": "GHSA-mjj8-gm8f-325h",
  "modified": "2026-05-08T15:31:18Z",
  "published": "2026-05-06T12:30:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43226"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/19e384a7d00d888303a8285977cdf1970c6cccd6"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/81248b1eb3c5954cc1fc7b33b7c03e34d20cb8c8"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/899ef00963ce76f9fc421a7d02335fe4ead6389b"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/9bcd7c00691a2db9745817d5ea79262a503b135c"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/9ff599a9be784a808c36765086e3db2144aa3b66"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/a179ac7be8f5a650d0068040705f4cddd6ca369c"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/ad22d24be635c6beab6a1fdd3f8b1f3c478d15da"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/f0f729bdffb08af32e0f54521b81b8a9e0321f16"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Loading…

Loading…

Loading…

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.


Loading…