sctp: disable BH before calling udp_tunnel_xmit_skb()
Affects Linux kernel releases from 5.11 when SCTP over UDP is enabled via net.sctp.udp_port and net.sctp.encap_port. Fixed in 6.6.160, 6.12.95, 6.18.37 and 7.0.10.
- Published
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- How many real-world setups can hit the bug, from the vendor's advisory and CISA data. It does not know your setup.What do these mean? →
- Specific setups only
- Fix
- Fixed in 6.6.160, 6.12.95, 6.18.37, 7.0.10
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
- Exploitation: none
- Automatable: yes
- Technical impact: partial
Summary
In the Linux kernel, the following vulnerability has been resolved: sctp: disable BH before calling udp_tunnel_xmit_skb() udp_tunnel_xmit_skb() / udp_tunnel6_xmit_skb() are expected to run with BH disabled. After commit 6f1a9140ecda ("add xmit recursion limit to tunnel xmit functions"), on the path: udp(6)_tunnel_xmit_skb() -> ip(6)tunnel_xmit() dev_xmit_recursion_inc()/dec() must stay balanced on the same CPU. Without local_bh_disable(), the context may move between CPUs, which can break the inc/dec pairing. This may lead to incorrect recursion level detection and cause packets to be dropped in ip(6)_tunnel_xmit() or __dev_queue_xmit(). Fix it by disabling BH around both IPv4 and IPv6 SCTP UDP xmit paths. In my testing, after enabling the SCTP over UDP: ip net exec ha sysctl -w net.sctp.udp_port=9899 ip net exec ha sysctl -w net.sctp.encap_port=9899 ip net exec hb sysctl -w net.sctp.udp_port=9899 ip net exec hb sysctl -w net.sctp.encap_port=9899 ip net exec ha iperf3 -s • without this patch: ip net exec hb iperf3 -c 192.168.0.1 --sctp [ 5] 0.00-10.00 sec 37.2 MBytes 31.2 Mbits/sec sender [ 5] 0.00-10.00 sec 37.1 MBytes 31.1 Mbits/sec receiver • with this patch: ip net exec hb iperf3 -c 192.168.0.1 --sctp [ 5] 0.00-10.00 sec 3.14 GBytes 2.69 Gbits/sec sender [ 5] 0.00-10.00 sec 3.14 GBytes 2.69 Gbits/sec receiver
Timeline
- CVE published
- CISA SSVC assessment
Exploitation: none · Automatable: yes · Technical impact: partial
- Record last updated
Affected versions
- Linux Linux
Version range not reported
- Linux Linux
5.11
- KernelLinux
From 5.11.0 · fixed in 6.6.160; From 6.7.0 · fixed in 6.12.95; From 6.13.0 · fixed in 6.18.37; From 6.19.0 · fixed in 7.0.10
References 6
git.kernel.org
Questions about CVE-2026-53070
What does this mean?
The SCTP code called udp_tunnel_xmit_skb() without first disabling bottom halves. The fix disables BH before that call.Source: git.kernel.org
Am I affected, and how do I check?
Kernel releases from 5.11.0 up to the fixed versions for each branch: before 6.6.160, 6.7.0 through before 6.12.95, 6.13.0 through before 6.18.37, and 6.19.0 through before 7.0.10. The issue only applies when SCTP over UDP is enabled by setting net.sctp.udp_port and net.sctp.encap_port. Check the running kernel with uname -r and the settings with sysctl net.sctp.udp_port net.sctp.encap_port.Source: git.kernel.org
What should I do about it?
Move to the fixed kernel for the branch in use: 6.6.160, 6.12.95, 6.18.37, or 7.0.10 or later.Source: git.kernel.org
Is it being exploited?
It is not in CISA's Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment does not mark exploitation as active. That does not mean it has not been attacked: vendors and researchers can report attacks before CISA lists them. No public exploit code is tracked.Source: cve.now feed data