CVE-2026-43226

What it actually does

This is a Linux kernel availability flaw in the Reliable Datagram Sockets over TCP (RDS/TCP) connection state machine. Under specific connection error and reset timing, an RDS connection can transition incorrectly out of RDS_CONN_ERROR and become stuck with shutdown work permanently queued. The result is a kernel-level denial of service condition affecting systems where RDS/RDS-TCP is enabled or reachable. The CVSS vector indicates remote, unauthenticated, low-complexity exploitation with no user interaction and high availability impact, but no direct confidentiality or integrity impact.

Why it matters to the business

A vulnerable Linux system that exposes or uses RDS/TCP could be made unstable or unavailable, potentially disrupting database, cluster, storage, or high-performance networking workloads that rely on kernel networking availability. Because this is a kernel issue, successful exploitation may affect the whole host rather than a single application. EPSS is currently low and stable, the issue is not in CISA KEV, and no public exploit maturity is reported, so urgency should be risk-based: prioritize internet- or untrusted-network-exposed systems and hosts with the RDS kernel modules enabled.

How an attack unfolds

An attacker first identifies a Linux host where RDS/TCP is enabled and reachable, commonly on the RDS TCP service port or within a trusted cluster network. The attacker then creates and manipulates RDS/TCP connection attempts so that the kernel connection path enters an error state. Due to the vulnerable state-transition logic, the connection can shortcut from RDS_CONN_ERROR back toward connection setup rather than being forced through the normal shutdown path. A subsequent reset can move the connection into RDS_CONN_RESETTING while shutdown work remains queued. The kernel shutdown handler then encounters an unexpected state, logs or triggers invalid connection-state handling, and leaves shutdown work stuck. Repeating or sustaining this behavior can degrade kernel networking resources or cause denial of service. There is no indication from the supplied data that this provides code execution or data theft.

How to fix it

Apply a Linux kernel update from the operating system or kernel vendor that includes the upstream fix for the RDS connection state-machine handling. No exact fixed package versions were provided in the input, so use vendor advisories and distribution errata to identify the corrected kernel build for each platform. Reboot into the fixed kernel after installation; merely installing the package is not sufficient if the running kernel remains vulnerable. If RDS is not required, reduce exposure by disabling or unloading the RDS modules, including rds and rds_tcp, and prevent them from autoloading via modprobe policy. Restrict access to RDS/TCP to trusted cluster nodes only, and block unsolicited access at network controls, especially TCP port 16385 where applicable. Where patching must be delayed, prioritize compensating controls on systems with the RDS modules loaded or reachable from untrusted networks.

How to confirm the fix worked

Confirm the running kernel, not just the installed package, is updated to a vendor build containing the fix. Validate with commands such as uname -r, package manager kernel version checks, and vendor advisory mapping. Check whether RDS is enabled by inspecting loaded modules with lsmod for rds and rds_tcp, and by checking listening sockets or firewall exposure for RDS/TCP, commonly TCP port 16385. After remediation, verify that rds and rds_tcp are not loaded if the service is not required, or that the fixed kernel remains stable during normal RDS connection setup and teardown testing. Review kernel logs after reboot and testing to ensure there are no recurring RDS invalid state, reset, or shutdown-work errors.

Typical attack path

1. Scan or otherwise identify Linux systems with RDS/RDS-TCP enabled or reachable from the attacker-controlled network.
2. Initiate RDS/TCP connection attempts to the target service, commonly over TCP port 16385 where RDS/TCP is deployed.
3. Force or race connection error/reset conditions so the kernel enters RDS_CONN_ERROR handling.
4. Trigger the vulnerable shortcut path that moves the connection back toward RDS_CONN_CONNECTING instead of normal shutdown.
5. Cause a later reset path to transition the connection into RDS_CONN_RESETTING with shutdown work queued.
6. Repeat the sequence to leave RDS shutdown work stuck and degrade or exhaust host availability.

How to detect it

To assess possible prior exploitation, review kernel and system logs from journalctl, /var/log/kern.log, /var/log/messages, /var/log/syslog, and centralized log collectors for RDS connection-state errors, invalid shutdown-state messages, repeated reset handling, kernel warnings, soft lockups, or unexplained service outages. Focus on periods with inbound connection attempts to RDS/TCP, especially TCP port 16385, and correlate kernel messages with firewall, NetFlow, VPC flow logs, IDS, or load balancer records showing repeated short-lived connections or resets from the same sources. On hosts, check whether rds or rds_tcp modules were loaded at the time of the event and whether there were abnormal kworker CPU usage, network stack instability, or host reboots. There are no known attacker-specific indicators in the supplied data; detection should therefore rely on behavioral evidence and kernel/RDS artifacts rather than hashes or malware indicators.

• DR_INV_CONN_STATE
• RDS_SHUTDOWN_WORK_QUEUED
• RDS_CONN_ERROR
• RDS_CONN_CONNECTING
• RDS_CONN_RESETTING
• rds_conn_init_shutdown
• rds_conn_path_drop
• rds_conn_path_transition
• rds_tcp_accept_one_path
• rds_tcp_state_change
• rds_tcp_reset_callbacks
• rds_tcp
• rds
• tcp/16385
• TCP port 16385

What your security team should do

• Inventory Linux systems for loaded rds and rds_tcp kernel modules and prioritize any hosts reachable from untrusted networks.
• Patch affected systems to a vendor-supplied fixed kernel and reboot into the fixed version.
• If RDS is not business-critical, disable and blacklist rds and rds_tcp to eliminate exposure.
• Restrict RDS/TCP network access to explicitly required trusted peers; block TCP port 16385 from untrusted segments where applicable.
• Add monitoring for RDS kernel error strings, invalid connection-state messages, and spikes in connection attempts to RDS/TCP services.
• Review kernel, syslog, and network-flow telemetry for signs of repeated RDS connection resets or denial-of-service activity before and after patching.
• Because EPSS is low, KEV is false, and exploit maturity is listed as none, treat this as a high-impact availability hardening item, escalating priority for systems that actually run RDS/TCP.