CVE-2026-43080

What it actually does

The flaw is an integer truncation/overflow in the Linux kernel L2TP transmit path for PPPoL2TP over UDP encapsulation. When a local process sends an oversized PPPoL2TP payload, l2tp_xmit_core calculates a UDP packet length that can exceed the 16-bit UDP length field. Vulnerable kernels may write the truncated value instead of rejecting the packet. Depending on kernel configuration and runtime settings, this can result in malformed UDP/L2TP traffic, kernel warnings, and potential local denial of service, especially on systems configured to panic on kernel WARN conditions.

Why it matters to the business

An authenticated local user or workload with access to the affected L2TP/PPPoL2TP functionality could disrupt host availability. The most likely outcome is a denial-of-service condition on Linux systems using or exposing L2TP-related kernel functionality, with greater operational risk on VPN, network gateway, telecom, or multi-tenant Linux hosts. Public exploitation is not currently indicated, the EPSS score is very low and stable, and the issue is not in CISA KEV, but it has been public for 98 days and should still be addressed through normal kernel maintenance because kernel availability bugs can have high operational impact when triggered locally.

How an attack unfolds

An attacker first obtains local code execution as a low-privileged user or compromises a workload running on an affected Linux host. They create a PPPoL2TP socket and an IPv6 UDP socket, connect the L2TP session through UDP encapsulation, and then write an oversized PPPoL2TP packet larger than the maximum representable UDP length. In vulnerable kernels, the L2TP transmit path fails to reject the oversized packet before assigning the UDP length field, causing the length to wrap or be truncated to 16 bits. The immediate effect may be malformed packet transmission and kernel warning output from the UDP/L2TP code path; on hardened or debugging-oriented systems where kernel warnings trigger a panic, this can crash the host and cause denial of service.

How to fix it

Upgrade to a Linux kernel version that includes the upstream L2TP fix to drop oversized UDP-encapsulated L2TP packets before assigning the 16-bit UDP length field. Because no exact fixed package versions were provided, use the security advisories and kernel packages from the relevant Linux distribution or vendor and verify that the patch for net/l2tp/l2tp_core.c is included. If immediate patching is not possible, reduce exposure by disabling or unloading unused L2TP/PPP-related kernel modules where operationally safe, restricting local shell/container access on systems that do not require it, limiting capabilities that allow creation or use of PPP/L2TP networking features, and ensuring production systems are not configured to panic on non-fatal kernel warnings unless that behavior is explicitly required.

How to confirm the fix worked

Confirm the running kernel has been updated to a vendor build containing the L2TP oversized UDP encapsulation fix. Validate that affected systems no longer produce kernel warnings from udp_set_len_short, l2tp_xmit_core, l2tp_xmit_skb, or pppol2tp_sendmsg when oversized PPPoL2TP traffic is attempted in an authorized test environment. Review kernel configuration and loaded modules to determine whether L2TP/PPP functionality is present, such as l2tp_core, l2tp_ppp, ppp_generic, and related modules. Use distribution tooling such as uname, package manager changelogs, vendor errata, or kernel source package references to confirm the patched kernel is installed and booted, not merely downloaded.

Typical attack path

1. Gain local execution on a vulnerable Linux system as an authenticated user or within a local workload/container context that can access the relevant socket functionality.
2. Confirm that the kernel includes L2TP/PPPoL2TP support and allows creation of PPPoL2TP and UDP sockets.
3. Create a PPPoL2TP socket and a UDP socket, then bind/connect them into a UDP-encapsulated L2TP session.
4. Send an oversized PPPoL2TP payload whose resulting UDP length exceeds 65535 bytes.
5. Trigger the vulnerable L2TP transmit path so the UDP length field is truncated rather than the packet being dropped.
6. Cause malformed network output, kernel warnings, service disruption, or a host crash if panic-on-warning behavior is enabled.

How to detect it

Look for evidence in kernel logs, system journals, crash dumps, and endpoint telemetry showing oversized PPPoL2TP send attempts or kernel warnings in the L2TP transmit path. Primary log sources include dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, /var/log/syslog, kdump/vmcore records, auditd syscall logs, EDR process telemetry, and network device logs if malformed L2TP/UDP packets were emitted. Search for stack traces referencing udp_set_len_short, l2tp_xmit_core, l2tp_xmit_skb, and pppol2tp_sendmsg. Investigate local processes that created AF_PPPOX/PPPoL2TP sockets, issued large writev/sendmsg calls to PPPoL2TP sockets, or ran shortly before a kernel warning or crash. If panic_on_warn is enabled, correlate unexpected reboots or kernel panics with these stack frames. There are no known named threat actors or public exploitation campaigns associated with this issue based on the provided data.

• udp_set_len_short
• l2tp_xmit_core
• l2tp_xmit_skb
• pppol2tp_sendmsg
• WARNING: ./include/linux/udp.h:38
• len >= 65536u
• net/l2tp/l2tp_core.c:1293
• net/l2tp/l2tp_core.c:1327
• net/l2tp/l2tp_ppp.c:302
• socket$pppl2tp
• socket$inet6_udp
• connect$pppl2tp
• writev

What your security team should do

• Prioritize patching Linux systems that provide VPN, L2TP, PPP, network gateway, telecom, hosting, CI/CD runner, or multi-tenant workload services.
• Identify systems with L2TP/PPPoL2TP kernel support enabled or modules loaded, and treat those as the primary exposure set.
• Apply vendor kernel updates and reboot into the fixed kernel; verify the active kernel version after reboot.
• Where L2TP is not required, disable or prevent loading of L2TP/PPP-related modules as a defense-in-depth mitigation.
• Review sysctl and kernel panic settings, especially panic_on_warn, because this issue is more disruptive when WARN conditions cause a host panic.
• Monitor kernel logs for L2TP/UDP warning traces and unusually large PPPoL2TP write activity from local processes.
• Because EPSS is low, stable, and there is no KEV listing, handle through normal vulnerability management timelines unless the host is high availability, multi-tenant, or uses L2TP heavily.