HIGH 7.1

CVE-2026-46322: Linux Kernel TUN Driver Memory Leak in XDP Processing

A memory leak exists in the Linux kernel's TUN network device driver. When the kernel attempts to construct a network packet (skb) from XDP program data and that construction fails, it doesn't properly release a memory page that was allocated earlier in the process. This causes a small chunk of memory to leak each time this failure occurs. In batch processing scenarios—common in virtual networking—multiple failures can accumulate, gradually consuming system memory and potentially degrading performance or availability.

Source data · NVD / CISA · public domain

CVSS
3.1 · 7.1 HIGH · CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H
Weaknesses (CWE)
Affected products
6 configuration(s)
Published / Modified
2026-06-09 / 2026-07-08

NVD description (verbatim)

In the Linux kernel, the following vulnerability has been resolved: tun: free page on build_skb failure in tun_xdp_one() When build_skb() fails in tun_xdp_one(), the function sets ret to -ENOMEM and jumps to the out label, which returns without freeing the page that vhost_net_build_xdp() allocated for the frame. As with the short-frame rejection path, tun_sendmsg() discards the per-buffer error and still returns total_len, so vhost_tx_batch() takes the success path and never frees the page. Each build_skb() failure in a batch leaks one page-frag chunk. Free the page before taking the error path, matching the put_page() the other error exits of tun_xdp_one() already perform.

8 reference(s) · View on NVD →

SEC.co analysis · AI-assisted, reviewed against source

Technical summary

CVE-2026-46322 is a resource exhaustion vulnerability in the Linux kernel's tun driver, specifically in the tun_xdp_one() function. When build_skb() fails during XDP frame processing, the function returns -ENOMEM without calling put_page() on the page allocated by vhost_net_build_xdp(). Because tun_sendmsg() masks per-buffer errors and returns total_len to indicate batch success, vhost_tx_batch() never detects the failure and thus never frees the leaked page. Unlike other error exits in tun_xdp_one() that correctly perform cleanup, this path bypasses page-frag deallocation, causing a page leak per build_skb() failure. The fix requires adding put_page() before the error return to match existing cleanup patterns.

Business impact

On systems running vulnerable Linux kernels with active TUN/vhost_net workloads (particularly virtual networking, container platforms, or VPN services), this vulnerability causes gradual memory resource exhaustion. Over time, repeated build_skb() failures deplete physical memory pages, potentially causing service degradation, application crashes due to memory pressure, or triggering the OOM killer. Systems under sustained load or handling high packet volume are most vulnerable. The impact is availability-focused: legitimate traffic may be starved of resources, and workload performance degrades as the kernel spends more time managing memory pressure.

Affected systems

The vulnerability affects Linux kernel versions that include the tun driver with XDP support. All six referenced vendor-product entries confirm Linux kernel across multiple versions. Systems running virtualization platforms (KVM/QEMU), container runtimes relying on vhost_net, or custom networking stacks using TUN+XDP are at risk. Verify your kernel version against vendor advisories and upstream kernel commit availability. Embedded systems, IoT devices, and specialized appliances using Linux kernels in networking roles should be assessed.

Exploitability

This is not a remote code execution or privilege escalation vector. Exploitation requires local context: the TUN device must be in active use with XDP programs, and the attacker must be able to trigger repeated build_skb() failures through malformed or unusual packet patterns. No special privileges are required to cause the leak—any process able to interact with a TUN device can potentially trigger the memory leak. The vulnerability is more of a denial-of-service risk than a direct security exploit, but it is nonetheless exploitable by a local or unprivileged user in shared or multi-tenant environments.

Remediation

Apply kernel patches that add the missing put_page() call in tun_xdp_one() before the error return path. Verify patch availability from your Linux distribution's security advisories or upstream kernel repositories. For immediate mitigation on systems where patching is delayed, restrict TUN device access to trusted processes and monitor memory usage for signs of page-frag exhaustion. Disabling XDP on TUN devices if not required also eliminates the vulnerable code path.

Patch guidance

Monitor your distribution's security update channels (Debian, Red Hat, Ubuntu, etc.) for kernel patches addressing CVE-2026-46322. Patches should explicitly add put_page() cleanup to the tun_xdp_one() error path. Verify against the upstream Linux kernel commit that fixes this issue. Test patches in non-production environments first, as kernel updates typically require reboot. Prioritize systems running high-traffic virtual networking or container workloads where the failure path is more likely to be triggered.

Detection guidance

Monitor kernel memory metrics, specifically page-frag allocation and reclamation. Tools like /proc/meminfo, slabtop, and memory profilers can show unusual page-cache growth tied to tun driver activity. Enable kernel logging (dmesg) to capture build_skb() failures or XDP processing errors. In virtual environments, track guest-to-host memory pressure patterns. Correlate memory degradation with TUN device packet rates and XDP rule changes. Network monitoring tools can track packet patterns that trigger build_skb() failures (malformed headers, unusual sizes) to identify active exploitation attempts.

Why prioritize this

Although not yet listed as actively exploited in the wild (KEV status: not added), this vulnerability scores 7.1 CVSS HIGH due to its local availability impact and ease of triggering in shared environments. Systems handling high-volume networking, virtualization clusters, or containerized workloads should patch promptly because accumulated memory leaks directly degrade service availability. It is a lower priority than remote code execution or authentication bypass vulnerabilities, but should not be deferred indefinitely on production systems with active TUN/XDP usage.

Risk score, explained

The CVSS 3.1 score of 7.1 (HIGH severity) reflects: (1) local attack vector—exploitation requires local system access or control of a TUN-using process; (2) low complexity—no special race conditions or multi-step exploitation required; (3) no privileges needed; (4) scope change—memory exhaustion on one service can affect other system services competing for the same physical memory; (5) high availability impact—resource exhaustion degrades or stops service. Confidentiality and integrity are not affected (only availability is impacted), moderating the score from critical, but the practical impact on infrastructure availability is significant.

Frequently asked questions

Can this vulnerability be exploited remotely?

No. This is a local resource exhaustion vulnerability requiring either direct TUN device access or running code on an affected system. However, in cloud or container environments where VMs or containers can be compromised, an attacker with foothold access can trigger the leak. It is not remotely exploitable over a network.

What systems are most at risk?

Systems running Linux kernel-based virtualization (KVM/QEMU), container platforms with vhost_net networking, and custom networking appliances using TUN+XDP. Shared multi-tenant systems where untrusted users can access TUN devices are particularly vulnerable. Dedicated servers running standard TCP/IP without TUN/vhost are generally not affected.

Will this cause a crash immediately?

No, it is a memory leak that accumulates over time. The severity depends on system memory size, workload intensity, and how often build_skb() failures occur. Small systems or high-traffic workloads will exhaust memory faster. Kernel OOM killer may terminate workloads, or the system may become unresponsive as memory pressure rises.

How do I know if my system is vulnerable?

Check your kernel version against your distribution's security advisory for CVE-2026-46322. If you run TUN devices with XDP (verify using 'ip link show' and 'ethtool -S' on tun interfaces), and your kernel version predates the vendor's patch, assume vulnerability. Contact your Linux distributor or check upstream kernel.org commit history for patch availability.

This analysis is provided for informational and educational purposes to help security teams understand and respond to CVE-2026-46322. SEC.co does not warrant the accuracy, completeness, or applicability of this content to any specific system or environment. Organizations must verify all technical claims, patch availability, and affected product versions against official vendor advisories and upstream sources before taking remediation action. The vulnerability details, CVSS score, and patch status are current as of the publication date; systems and threat landscape evolve continuously. Consult your Linux distribution's security team, system manufacturer, and internal IT governance before applying patches or operational changes. This document does not constitute security advice tailored to your organization; engage qualified security professionals for deployment-specific guidance. Source: NVD (public-domain), retrieved 2026-07-16. Analysis generated by SEC.co (claude-haiku-4-5).