CVE-2026-43230

What it actually does

This is a Linux kernel denial-of-service flaw in the RDS (Reliable Datagram Sockets) networking subsystem. A reconnect worker can be canceled before it is actually scheduled, leaving the internal reconnect-pending bit set indefinitely. Once that stale state is reached, affected RDS connections may fail to reconnect, causing loss of availability for workloads that depend on RDS networking. The issue does not provide confidentiality or integrity impact based on the available description; its impact is service disruption.

Why it matters to the business

Systems using the Linux kernel RDS networking subsystem can experience network service interruption or application downtime if the reconnect logic becomes stuck. The CVSS score indicates high availability impact, but current public exploit maturity is listed as none, EPSS is low and stable, and it is not listed in CISA KEV, so remediation should be prioritized based on whether RDS is enabled or used in production. Organizations with clustered, database, storage, or high-availability workloads relying on RDS should treat this as more urgent because failed reconnection can translate directly into outages or degraded service.

How an attack unfolds

An attacker would need to reach a system or workload path that exercises Linux RDS connection handling. They would attempt to force or induce RDS connection disruption and reconnection behavior, such as repeated connection attempts, resets, or timing-sensitive disconnect conditions. If the reconnect worker is canceled before it is scheduled, the kernel may leave the reconnect-pending bit set permanently. After that, the affected connection path may not properly reconnect, producing a denial of service for applications depending on that RDS channel. There is no indication from the provided information that successful exploitation yields code execution, privilege escalation, or data access.

How to fix it

Apply the Linux kernel update from the relevant distribution or vendor that includes the upstream fix for net/rds reconnect-pending state cleanup. Because no exact fixed versions were provided, validate remediation through vendor advisories, kernel changelogs, or package metadata for the affected kernel stream. If RDS is not required, reduce exposure by disabling or preventing loading of the RDS kernel module and restricting RDS-related traffic at network boundaries. Where immediate patching is not possible, prioritize compensating controls on systems where RDS is enabled, reachable, or used by critical workloads.

How to confirm the fix worked

Confirm the running kernel package is at or above the vendor-fixed build that includes the net/rds reconnect-pending cleanup fix. Verify whether the RDS module is loaded or available using standard host inventory and kernel module checks, and confirm it is disabled if not required. Review vendor kernel changelogs for references to clearing the reconnect-pending bit when canceling the reconnect worker. In staging, exercise RDS connection interruption and reconnection scenarios and confirm connections recover normally without persistent reconnect failure. Validate firewall or segmentation controls prevent untrusted access to RDS-exposed services where applicable.

Typical attack path

1. Identify Linux systems where the RDS kernel subsystem is available, loaded, or reachable over the network.
2. Establish or influence RDS communication with the target system or a dependent service.
3. Trigger connection failure, cancellation, or rapid reconnect timing conditions.
4. Cause the reconnect worker cancellation path to leave the reconnect-pending state set.
5. Prevent normal RDS reconnection, resulting in service degradation or outage for dependent applications.

How to detect it

There are no unique public indicators of exploitation from the provided information, and this flaw is a denial-of-service condition rather than a compromise that normally leaves attacker-specific artifacts. To assess possible prior exploitation, review kernel logs, system logs, network telemetry, and application availability data for unexplained RDS reconnect failures, repeated connection resets, sudden inability of RDS-dependent applications to reconnect, or service outages correlated with inbound RDS traffic or connection churn. Useful sources include journalctl, /var/log/kern.log, /var/log/messages, dmesg output, network flow records, firewall logs, load balancer logs, and application logs for services using RDS. Because symptoms may look like ordinary instability, correlate timing across multiple sources and compare against patch status and whether the rds module was loaded at the time.

What your security team should do

• Inventory Linux systems for RDS kernel module availability, loaded state, and business-critical workloads that depend on RDS.
• Prioritize patching systems where RDS is enabled, exposed to untrusted networks, or used by high-availability applications.
• If RDS is unused, disable or blacklist the RDS module and enforce configuration management to prevent re-enablement.
• Monitor kernel, system, and application logs for recurring RDS connection failures, reconnect anomalies, or unexplained service outages.
• Track Linux distribution advisories for the exact fixed kernel versions because the input did not provide per-package fixed versions.
• Treat current exploitation likelihood as lower than many internet-exposed flaws because EPSS is low and stable, exploit maturity is listed as none, and the CVE is not in KEV; still remediate based on asset criticality and RDS exposure.