CVE-2026-53070: Linux Kernel SCTP over UDP Packet Loss DoS

Technical summary

The vulnerability stems from missing local_bh_disable() calls around udp_tunnel_xmit_skb() and udp_tunnel6_xmit_skb() invocations in the SCTP subsystem. Following commit 6f1a9140ecda, the tunnel transmission path invokes dev_xmit_recursion_inc()/dec() to track call depth and prevent pathological recursion. These increment/decrement operations are per-CPU and assume atomic execution on a single core. Without BH disabling, the kernel context can migrate between CPUs between the increment and decrement, leaving the recursion counter unbalanced on one or more CPUs. Subsequent packets trigger incorrect recursion-limit checks in ip_tunnel_xmit() or __dev_queue_xmit(), resulting in packet drops. The fix wraps both IPv4 and IPv6 SCTP UDP transmission paths with local_bh_disable()/enable() to enforce CPU affinity and maintain counter symmetry.

Business impact

Organizations deploying SCTP over UDP for real-time communications, clustering, or high-throughput data transfer face severe service degradation. Network throughput collapses to ~1% of expected capacity, rendering SCTP-over-UDP unsuitable for production use until patched. This affects telephony platforms, distributed databases, and telecom infrastructure relying on SCTP's congestion control and ordered delivery semantics. Even non-SCTP deployments may face minor impacts if kernel packet forwarding or tunneling features are enabled alongside other UDP-based tunnels, though the primary attack surface is SCTP-specific.

Affected systems

The vulnerability affects all Linux kernel versions that include SCTP over UDP support with the referenced commit 6f1a9140ecda (kernels 5.3+). Systems with CONFIG_SCTP and UDP encapsulation enabled are at risk. Unaffected are systems with SCTP disabled, systems using only native SCTP (not encapsulated), or older kernels predating the tunneling recursion limit feature. Verify kernel version and SCTP configuration via 'cat /boot/config-$(uname -r) | grep SCTP' and check if net.sctp.udp_port is set to a non-zero value.

Exploitability

This is a non-malicious correctness bug with no direct remote exploitation vector. However, an attacker on the same network can trivially trigger packet loss by sending SCTP over UDP traffic to or from the affected system, causing availability impact without authentication or special privileges. The vulnerability is triggered passively when SCTP over UDP traffic flows, making it exploitable by any network participant who can reach the target. Weaponization is straightforward: sustained SCTP traffic causes persistent DoS conditions.

Remediation

Apply a kernel patch that restores BH disabling around SCTP UDP transmission calls. The fix is lightweight (2–4 lines of code) and carries no performance penalty—in fact, benchmarks show a 86× throughput improvement post-patch (31 Mbps → 2.69 Gbps in testing). Upgrade to a patched kernel version supplied by your distribution. If immediate patching is not feasible, disable SCTP over UDP by ensuring net.sctp.udp_port remains unset or is set to 0, falling back to native SCTP or alternative transport protocols.

Patch guidance

Check your kernel version against your distribution's security advisory to identify patched releases. Most major Linux distributions (Red Hat, Debian, Ubuntu, SUSE) began releasing fixes in June–July 2026. Verify the patch by confirming that local_bh_disable() calls are present in the sctp_v4_xmit_tunnel() and sctp_v6_xmit_tunnel() code paths (or equivalent SCTP UDP transmission functions). After updating, test SCTP over UDP throughput to confirm recovery to expected baseline; pre-patch systems will show <50 Mbps on most hardware, while patched systems return to multi-Gbps performance. Reboot is required for kernel updates.

Detection guidance

Monitor for unexpectedly low throughput on flows tagged with SCTP (protocol 132) or traffic on configured sctp.udp_port values. Kernel metrics from /proc/net/snmp or netstat may show dropped packets correlating with SCTP over UDP activity. Check dmesg for warnings from dev_xmit_recursion or tunnel code paths if verbose logging is enabled. On affected systems, iperf3 --sctp benchmarks will report <100 Mbps throughput despite adequate network capacity. Correlate low SCTP performance with kernel version to confirm the vulnerability; patched kernels show 1–10 Gbps SCTP throughput depending on hardware.

Why prioritize this

While not remotely exploitable in the traditional sense, this vulnerability causes immediate and severe availability impact (>99% packet loss) to any SCTP over UDP deployment. The fix is trivial, zero-risk, and widely available. Prioritize patching for systems using SCTP encapsulation; defer for systems with SCTP disabled. The high CVSS (7.5) reflects availability impact; actual remediation effort is minimal.

Risk score, explained

CVSS 3.1 score of 7.5 (HIGH) is appropriate: network-accessible, low-complexity trigger (SCTP over UDP traffic), no privilege or user interaction required, and high availability impact (near-total packet loss). The score does not reflect confidentiality or integrity breaches, only denial of service. Organizations with active SCTP over UDP deployments should treat this as critical; others with SCTP disabled can treat it as medium priority.

Frequently asked questions