{ "schema_version": "1.6.1", "id": "RPI-CVE-2026-43226", "modified": "2026-10-09T11:39:44Z", "upstream": [ "CVE-2026-43226" ], "published": "2026-05-06T11:29:17Z", "summary": "net/rds: No shortcut out of RDS_CONN_ERROR", "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'll 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't 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't error out\n and get stuck, if we ever hit weird state transitions\n like this again.\"", "severity": [ { "type": "CVSS_V3", "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H" } ], "affected": [ { "package": { "ecosystem": "Raspberry Pi OS:12", "name": "linux" }, "versions": [ "1:6.1.47-1+rpt4" ], "ecosystem_specific": { "binaries": [ { "binary_name": "linux-image-6.1.0-rpi3-rpi-2712", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v6", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v7", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v7l", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v8", "binary_version": "1:6.1.47-1+rpt4" } ] }, "database_specific": { "per_version": { "1:6.1.47-1+rpt4": { "linux_commit": "655fc658a15ae7a6f37103754adb39ba52a9a14e", "upstream_version": "6.1.47", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.1.165", "compiled_filter": false } } } } ], "references": [ { "type": "ADVISORY", "url": "https://www.cve.org/CVERecord?id=CVE-2026-43226" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/9bcd7c00691a2db9745817d5ea79262a503b135c" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/a179ac7be8f5a650d0068040705f4cddd6ca369c" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/19e384a7d00d888303a8285977cdf1970c6cccd6" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/f0f729bdffb08af32e0f54521b81b8a9e0321f16" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/81248b1eb3c5954cc1fc7b33b7c03e34d20cb8c8" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/899ef00963ce76f9fc421a7d02335fe4ead6389b" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/9ff599a9be784a808c36765086e3db2144aa3b66" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/ad22d24be635c6beab6a1fdd3f8b1f3c478d15da" } ], "database_specific": { "source": "https://git.kernel.org/pub/scm/linux/security/vulns.git", "upstream_modified": "2026-08-05T13:16:28Z", "severity": { "source": "kernel CNA", "cvss_v3_score": 7.5, "cvss_v3_severity": "High", "scenario": "AV:N - The vulnerable code is in the RDS/TCP passive accept path reached by remote TCP connections to the kernel RDS listener on port 16385. No local syscall or physical access is required in a deployment where RDS/TCP is enabled and reachable.\nAC:L - The attacker can drive the relevant error and reconnect sequence by opening, closing, and reconnecting TCP connections; the queued-shutdown timing is repeatable and under attacker influence. There is no requirement for a rare victim-controlled state beyond an active RDS/TCP deployment.\nPR:N - The accept path runs before any RDS authentication or credential check, and RDS/TCP does not authenticate the remote peer before reaching rds_tcp_accept_one_path. A network attacker only needs the ability to connect to the listener.\nUI:N - Exploitation does not require a user to open a file, mount anything, or perform an action. The attacker triggers it through network connection sequencing.\nS:U - The impact remains within the kernel/RDS networking security authority. It does not cross a VM, IOMMU, or other separate security boundary.\nC:N - The bug is a connection state-machine error and I found no memory disclosure path, out-of-bounds read, or use-after-free primitive. It does not expose kernel or application data.\nI:N - The fix addresses invalid RDS connection state transitions, not memory corruption or unauthorized data modification. I found no arbitrary write, control-flow hijack, or integrity-impacting primitive.\nA:H - The invalid shortcut can leave an RDS/TCP connection path stuck with shutdown/reconnect work state permanently wedged, denying RDS availability for affected peer paths until external recovery. Because it is remotely and repeatedly triggerable against a network service, the availability impact is high." } } }