CVE-2026-53070

What it actually does

This Linux kernel flaw is a race/context-handling defect in the SCTP-over-UDP transmit path. The kernel calls udp_tunnel_xmit_skb() and udp_tunnel6_xmit_skb() without disabling bottom halves, even though those tunnel transmit helpers expect to run with bottom halves disabled. Under certain scheduling conditions, transmit recursion accounting can be incremented on one CPU and decremented on another, breaking per-CPU accounting assumptions. The practical result is incorrect recursion-depth detection in the network transmit path, which can cause legitimate SCTP-over-UDP packets to be dropped in ip_tunnel_xmit(), ip6_tunnel_xmit(), or __dev_queue_xmit(). The vulnerability primarily affects availability and network reliability for systems using SCTP UDP encapsulation.

Why it matters to the business

Organizations that rely on SCTP-over-UDP, such as telecom, signaling, clustered services, or specialized transport deployments, may experience severe packet loss, degraded throughput, unstable application behavior, or service disruption. The issue is not currently listed in CISA KEV, has no known ransomware association, and has low EPSS probability, so broad opportunistic exploitation is unlikely; however, exposed or business-critical SCTP-over-UDP workloads should still be prioritized because the impact can be operationally significant when the affected feature is enabled.

How an attack unfolds

An attacker would need a reachable service or network path using SCTP over UDP encapsulation on an affected Linux kernel. By sending or inducing SCTP-over-UDP traffic at sufficient volume or under timing conditions that exercise the tunnel transmit path, the attacker may trigger the race in transmit recursion accounting. Because bottom halves are not disabled around the UDP tunnel transmit operation, execution can move between CPUs and leave recursion accounting inconsistent. The kernel may then falsely detect excessive transmit recursion and drop packets. This can degrade throughput or create a denial-of-service condition for applications dependent on that SCTP transport. There is no indication from the supplied intelligence that this enables code execution, privilege escalation, or data disclosure.

How to fix it

Upgrade to a Linux kernel build that includes the upstream fix which disables bottom halves around both IPv4 and IPv6 SCTP UDP transmit paths. Because no distribution-specific affected packages or fixed versions were provided, use the fixed kernel version or advisory from the relevant Linux distribution, appliance vendor, cloud image provider, or kernel maintenance branch. If immediate patching is not possible, reduce exposure by disabling SCTP-over-UDP encapsulation where it is not required, restricting network access to SCTP-over-UDP endpoints, rate-limiting untrusted traffic, and monitoring for abnormal packet loss or throughput degradation. Validate whether sysctl settings such as net.sctp.udp_port and net.sctp.encap_port are enabled, as the issue is most relevant when SCTP UDP encapsulation is in use.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel includes the SCTP UDP transmit fix from the vendor or upstream stable branch. Check the active kernel version with uname -r and compare it against the relevant vendor advisory. Review SCTP UDP encapsulation settings using sysctl net.sctp.udp_port and sysctl net.sctp.encap_port where available. If the feature is required, run controlled SCTP-over-UDP throughput and packet-loss tests before and after patching to confirm stable transmission. Also verify that no older vulnerable kernel remains loaded after package installation; a reboot is usually required for kernel fixes to take effect.

Typical attack path

1. Identify a Linux system or service using SCTP over UDP encapsulation.
2. Confirm that SCTP-over-UDP traffic can be sent to or through the target system.
3. Generate sustained or carefully timed SCTP-over-UDP traffic toward the affected service or path.
4. Trigger the transmit path where udp_tunnel_xmit_skb() or udp_tunnel6_xmit_skb() is called without bottom halves disabled.
5. Cause incorrect per-CPU transmit recursion accounting.
6. Induce packet drops, reduced throughput, or service instability for SCTP-dependent applications.

How to detect it

Detection should focus on signs of attempted or successful availability degradation rather than host compromise, because the described flaw causes packet drops and throughput loss rather than known code execution. Review network telemetry, kernel logs, service logs, and performance metrics for abnormal SCTP-over-UDP traffic volume, sudden throughput collapse, retransmission spikes, packet drops, or service timeouts. Useful sources include NetFlow/IPFIX, firewall logs, load balancer logs, host network interface counters, application logs for SCTP-dependent services, kernel ring buffer output, syslog, and monitoring data for packet drops and retransmits. Investigate systems where SCTP-over-UDP is enabled through net.sctp.udp_port or net.sctp.encap_port and where unexplained service degradation coincides with high UDP traffic to the configured encapsulation port. There are no known public exploit strings, malware artifacts, file paths, process names, registry keys, or actor-specific indicators associated with this vulnerability in the provided intelligence.

• net.sctp.udp_port
• net.sctp.encap_port
• udp_tunnel_xmit_skb
• udp_tunnel6_xmit_skb
• ip_tunnel_xmit
• ip6_tunnel_xmit
• __dev_queue_xmit

What your security team should do

• Inventory Linux systems that have SCTP enabled or support SCTP-over-UDP encapsulation, especially telecom, signaling, clustering, and network infrastructure hosts.
• Prioritize patching systems where net.sctp.udp_port or net.sctp.encap_port is configured and reachable from untrusted or semi-trusted networks.
• Apply vendor-provided kernel updates and reboot into the fixed kernel.
• If patching must be delayed, restrict access to SCTP-over-UDP services using host firewalls, network ACLs, security groups, or perimeter filtering.
• Disable SCTP-over-UDP encapsulation where there is no business requirement for it.
• Monitor SCTP-dependent services for packet loss, degraded throughput, retransmissions, or unexplained service instability.
• Because exploit maturity is currently listed as none and EPSS is low, treat this as a targeted availability risk rather than an internet-wide emergency unless SCTP-over-UDP is business-critical.