CVE-2026-46322

What it actually does

This flaw is a Linux kernel memory-leak vulnerability in the TUN/TAP networking path when XDP/vhost networking is used. If build_skb() fails inside tun_xdp_one(), a page fragment allocated by vhost_net_build_xdp() is not released before the error path returns. Because the caller can treat the operation as successful, repeated failures can leak kernel memory page fragments. Over time, this can exhaust available memory and degrade or crash the host, causing a denial of service. The issue does not directly provide code execution or data disclosure based on the available description.

Why it matters to the business

Successful exploitation can cause Linux systems that use TUN/TAP, vhost-net, virtualization, container networking, or related high-performance packet paths to suffer memory exhaustion, degraded networking, workload interruption, or host instability. This is most relevant for infrastructure running virtual machines, network appliances, container platforms, VPN gateways, or packet-processing workloads. The vulnerability is not currently listed in CISA KEV, is not reported as ransomware-used, and has a very low EPSS score, so broad active exploitation is not indicated; however, denial-of-service risk remains important for exposed multi-tenant or untrusted local workload environments.

How an attack unfolds

An attacker needs the ability to trigger traffic through a vulnerable Linux kernel TUN/TAP path that reaches tun_xdp_one(), typically through local access to a workload, virtualized networking path, or an interface that can drive vhost-net/TUN packet handling. The attacker repeatedly sends traffic or frames designed to create memory pressure or otherwise cause build_skb() allocation failures. When build_skb() fails, the vulnerable error path returns without freeing the allocated page fragment. Repeating this condition leaks kernel memory page fragments batch after batch. As unreclaimed memory accumulates, the system can experience packet drops, allocation failures, service degradation, out-of-memory conditions, or kernel instability, resulting in denial of service.

How to fix it

Upgrade to a Linux kernel version that includes the fix for the TUN tun_xdp_one() page release bug. The corrective change frees the allocated page before returning on the build_skb() failure path, matching other error exits in the function. If vendor fixed package versions are available from the Linux distribution or appliance vendor, apply those kernel updates and reboot into the fixed kernel. Where immediate patching is not possible, reduce exposure by limiting untrusted access to TUN/TAP devices, restricting creation of virtual network devices, controlling access to /dev/net/tun, limiting untrusted local workloads, applying container/VM resource limits, and monitoring for memory pressure on hosts using vhost-net, XDP, or TUN/TAP networking.

How to confirm the fix worked

Confirm the running kernel includes the vendor patch for the TUN tun_xdp_one() build_skb() failure leak. Validate both the installed kernel package and the active booted kernel, since Linux kernel fixes usually require rebooting into the updated kernel. Review vendor advisories for the exact fixed kernel package applicable to the distribution. Where source verification is possible, confirm the tun_xdp_one() error path frees or releases the allocated page before returning after build_skb() failure. Operationally, test representative TUN/TAP or vhost-net traffic under controlled load and verify that kernel memory usage does not grow persistently after allocation-failure conditions.

Typical attack path

1. Gain the ability to generate traffic through a vulnerable Linux TUN/TAP or vhost-net packet-processing path.
2. Create conditions that repeatedly cause build_skb() failures, such as sustained packet pressure combined with memory pressure.
3. Trigger the vulnerable tun_xdp_one() error path where allocated page fragments are not released.
4. Repeat the operation to accumulate leaked kernel memory.
5. Cause memory exhaustion, network degradation, workload failure, or host-level denial of service.

How to detect it

There are no definitive public indicators of exploitation for this vulnerability from the provided information, and exploitation may look like generic memory pressure rather than a unique compromise pattern. To assess possible prior exploitation, review kernel logs, system journals, hypervisor/container host telemetry, and monitoring data for unexplained memory growth correlated with TUN/TAP, vhost-net, XDP, VPN, VM, or container network activity. Look for repeated out-of-memory events, page allocation failures, kernel allocation warnings, packet-processing degradation, and service restarts on systems that expose /dev/net/tun or run virtual networking workloads. Investigate spikes in traffic through TUN/TAP interfaces immediately preceding OOM kills or host instability. Because this is a denial-of-service memory leak, focus on resource-exhaustion artifacts rather than persistence, credential access, or malware indicators.

• /dev/net/tun
• tun_xdp_one
• vhost_net_build_xdp
• build_skb
• vhost_net
• Out of memory
• oom-killer
• page allocation failure
• Memory allocation failure
• Killed process
• invoked oom-killer
• kernel: Out of memory
• kernel: page allocation failure
• kernel: build_skb
• kernel: vhost_net
• kernel: tun

What your security team should do

• Inventory Linux systems that use TUN/TAP, vhost-net, virtualization, container networking, VPN services, or XDP-enabled packet paths.
• Prioritize patching hosts that run untrusted local workloads, multi-tenant virtualization, containers, network appliances, VPN gateways, or high-throughput packet-processing services.
• Apply vendor kernel updates that contain the fix and reboot systems into the updated kernel.
• Restrict access to /dev/net/tun and the ability to create or manipulate TUN/TAP devices to trusted users and services only.
• Apply memory, process, and network-rate limits to untrusted containers, VMs, and local workloads where feasible.
• Monitor affected systems for unexplained kernel memory growth, OOM events, allocation failures, and vhost/tun-related network degradation.
• Because there is no current KEV listing, no known ransomware association, very low EPSS, and no public exploit maturity reported, handle as a reliability and local denial-of-service patching priority rather than an active mass-exploitation emergency unless local threat exposure is high.