CVE-2026-43057
High · 7.5CVSS
7.5
EPSS
0.8%
Published
May 1, 2026
CISA due date
—
Cloudanix analysis
A flaw in Linux network packet handling could let a remote attacker disrupt affected systems by sending specially crafted tunneled IPv6 traffic.
- Exploitation
- Remote Unauthenticated
- Attacker needs
- None
- Complexity
- Low
- Impact
- Denial Of Service
- Component
- OS kernel
- Class
- Denial of service
- Remediation
- Upgrade
- Effort
- Medium
- Patch risk
- Low
What it actually does
CVE-2026-43057 is a Linux kernel networking flaw in the handling of tunneled traffic when IPv6 checksum offload cannot be used and Generic Segmentation Offload fallback is required. Certain tunneled IPv6 packets, especially those involving IPv6 extension headers or tunneled payloads without a standard inner IP protocol, can be processed using the wrong header-length assumptions. Because segmentation and checksum handling occur in the kernel network stack, a remote unauthenticated sender may be able to trigger a high-impact availability failure such as packet-processing errors, kernel warnings, interface disruption, soft lockups, or a kernel crash depending on driver, offload configuration, and traffic path.
Why it matters to the business
Systems that process untrusted IPv6 or tunneled network traffic may be susceptible to remote denial of service. The most likely consequence is disruption of Linux-based servers, routers, gateways, load balancers, VPN endpoints, container hosts, or appliances that rely on the affected kernel networking path. The issue is not known to be in CISA KEV, is not reported as ransomware-used, has low EPSS, and has no stated public exploit maturity, which lowers immediate mass-exploitation urgency; however, the CVSS availability impact is high and exposed network infrastructure should still be patched during the next expedited kernel maintenance window.
How an attack unfolds
An attacker sends specially formed tunneled IPv6 traffic toward a Linux system that processes or forwards the packets with relevant checksum and segmentation offload features enabled. The crafted traffic uses IPv6 extension headers or a tunneled encapsulation where the kernel must fall back from IPv6 checksum offload to software Generic Segmentation Offload. Due to incorrect handling of tunneled inner header length, the kernel may make segmentation or checksum decisions using the wrong header context. Repeated delivery of such packets can stress or fault the affected network path, potentially causing degraded packet processing, interface instability, kernel warnings, soft lockups, or a crash that results in denial of service.
How to fix it
Apply a Linux kernel update from the relevant distribution or appliance vendor that includes the upstream fix for correct handling of tunneled traffic on IPV6_CSUM GSO fallback. No fixed version was provided in the input, so remediation should be tracked through vendor advisories and kernel changelogs for this CVE. Where immediate patching is not possible, reduce exposure by limiting untrusted IPv6 tunneled traffic, filtering unnecessary IPv6 extension-header traffic at network boundaries where operationally safe, and disabling risky offload features on exposed interfaces as a temporary mitigation, for example disabling TSO/GSO and IPv6 transmit checksum offload with ethtool. Mitigations that disable offload can reduce performance and should be tested before broad deployment.
How to confirm the fix worked
Confirm the running kernel package is updated to a vendor build that explicitly includes the fix for this CVE or the corresponding upstream networking patch. Verify that systems have been rebooted into the patched kernel, not merely that the package is installed. Inventory exposed Linux systems that terminate or forward IPv6 tunnels and confirm their kernel versions against vendor advisories. For temporary mitigations, validate interface offload state with commands such as ethtool -k <interface> and confirm that TSO, GSO, and relevant transmit checksum offloads are disabled where intended. After patching or mitigation, perform controlled regression testing with representative tunneled IPv6 traffic and monitor for kernel warnings, packet drops, interface resets, or crashes.
Typical attack path
- Identify a Linux host, gateway, appliance, or virtualized workload that accepts or forwards IPv6 tunneled traffic from an untrusted network.
- Send crafted tunneled IPv6 packets that include IPv6 extension-header conditions or non-standard inner protocol layouts requiring software GSO fallback.
- Trigger the vulnerable kernel code path where checksum offload and segmentation fallback evaluate the wrong header length for tunneled traffic.
- Repeat traffic to increase the chance of network-stack instability, packet-processing failure, or kernel crash.
- Cause service interruption, host reboot, interface failure, or degraded availability for workloads depending on the affected system.
How to detect it
Retrospective detection is difficult because exploitation may leave only availability and kernel-stability artifacts rather than a unique application-level indicator. Review kernel logs, system journals, crash dumps, netconsole output, hypervisor console logs, and network-device telemetry for unexplained crashes or interface instability following bursts of tunneled IPv6 traffic. Focus on events involving IPv6, tunneling, segmentation offload, checksum offload, GSO, TSO, SCTP-over-UDP, UDP tunnels, or extension-header traffic. Correlate kernel warnings, oopses, soft lockups, watchdog events, and interface resets with flow logs or packet captures showing inbound IPv6 encapsulated traffic. If crash dumps are available, inspect stack traces for Linux networking, skb segmentation, GSO, tunnel, IPv6, UDP tunnel, or SCTP-related functions. Network telemetry should be reviewed for unusual volumes of IPv6 packets with extension headers, fragmented or encapsulated IPv6 flows, or anomalous UDP tunnel traffic directed at Linux systems that experienced instability.
- kernel: Oops:
- kernel: BUG:
- kernel: WARNING:
- kernel: panic
- kernel: soft lockup
- kernel: hard LOCKUP
- kernel: NETDEV WATCHDOG
- kernel: transmit queue timed out
- segmentation offload
- checksum offload
- GSO
- TSO
- IPV6_CSUM
- IPv6 extension header
- SCTP in UDP
- UDP tunnel
- ethtool -k
What your security team should do
- Prioritize patching Linux systems that process untrusted IPv6 traffic, terminate tunnels, forward encapsulated traffic, or serve as network gateways, VPN endpoints, routers, load balancers, Kubernetes/container hosts, or virtualization hosts.
- Track distribution and appliance vendor advisories because fixed versions are vendor-specific and were not supplied in the input.
- If patching is delayed, restrict unnecessary tunneled IPv6 traffic and IPv6 extension-header traffic at perimeter and segmentation controls where safe for business operations.
- Consider temporary disabling of TSO, GSO, and IPv6 transmit checksum offload on high-risk exposed interfaces, with performance testing and rollback planning.
- Monitor kernel, system, and network-device logs for crashes, soft lockups, watchdog events, interface resets, or packet-processing anomalies correlated with tunneled IPv6 traffic.
- Because EPSS is low and there is no KEV listing or known public exploit maturity, use risk-based prioritization rather than emergency all-hands response, while still treating internet-exposed network infrastructure as higher priority.
The record
In the Linux kernel, the following vulnerability has been resolved: net: correctly handle tunneled traffic on IPV6_CSUM GSO fallback NETIF_F_IPV6_CSUM only advertises support for checksum offload of packets without IPv6 extension headers. Packets with extension headers must fall back onto software checksumming. Since TSO depends on checksum offload, those must revert to GSO. The below commit introduces that fallback. It always checks network header length. For tunneled packets, the inner header length must be checked instead. Extend the check accordingly. A special case is tunneled packets without inner IP protocol. Such as RFC 6951 SCTP in UDP. Those are not standard IPv6 followed by transport header either, so also must revert to the software GSO path.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|