CVE-2026-46321

What it actually does

This is a Linux kernel denial-of-service flaw in the TUN/TAP and vhost-net transmit path. When tun_xdp_one() rejects an Ethernet frame shorter than ETH_HLEN, it returns an error without freeing a page-fragment allocation created earlier by vhost_net_build_xdp(). Because tun_sendmsg() can discard that error and report success, the vhost transmit batching code follows the success path and does not release the memory. A local process able to access /dev/net/tun and /dev/vhost-net can repeatedly submit malformed short TX descriptors and leak kernel memory until the host experiences memory exhaustion, OOM kills, severe service degradation, or a kernel panic/reboot.

Why it matters to the business

Successful exploitation can make a Linux host unstable or unavailable by exhausting memory from a local context. This can disrupt virtualized workloads, container platforms, network appliances, CI/build hosts, or any system exposing TUN/TAP and vhost-net functionality to untrusted or semi-trusted local users. The vulnerability is not listed in CISA KEV, is not known to be used in ransomware campaigns, and currently has low EPSS likelihood, but the impact is high for multi-tenant systems because a single local actor may be able to degrade or crash the host.

How an attack unfolds

An attacker first gains local code execution or access to an environment where /dev/net/tun and /dev/vhost-net are available. They create or attach a TUN/TAP device as a vhost-net backend, then prepare virtio-net transmit descriptors whose effective packet length, after subtracting the virtio-net header, is shorter than the minimum Ethernet header length. When the descriptors are submitted and the vhost queue is kicked, the kernel allocates page-fragment memory while building the XDP buffer, rejects the short frame, and fails to free the allocation. By repeating this in a tight loop, each batch leaks additional kernel memory. Eventually the system enters memory pressure, begins OOM killing processes, becomes unresponsive, or panics/reboots.

How to fix it

Apply the Linux kernel update from the relevant distribution or appliance vendor that includes the fix to free the allocated page before returning -EINVAL in tun_xdp_one(). If no fixed package version is available from the vendor yet, reduce exposure by restricting access to /dev/net/tun and /dev/vhost-net to trusted users and workloads only, avoiding passthrough of these device nodes into untrusted containers, disabling unnecessary TUN/TAP or vhost-net usage, and enforcing device cgroup, SELinux, AppArmor, or container runtime policies that prevent untrusted local processes from opening these devices. Reboot into the updated kernel after patching; live patching may not be sufficient unless the vendor explicitly states that this kernel path is covered.

How to confirm the fix worked

Confirm the running kernel includes the vendor fix for the TUN/TAP vhost-net short-frame leak, not merely that an updated package is installed. Validate by checking the active kernel version with uname -r, reviewing distribution security advisories/changelogs for this vulnerability or the tun_xdp_one() page-free fix, and ensuring the system has been rebooted into the fixed kernel. Confirm exposure reduction by verifying that untrusted users and workloads cannot open /dev/net/tun or /dev/vhost-net, and that containers or sandboxes are not granted these device nodes unless required. In a controlled non-production test environment, a proof-of-concept should no longer cause steadily increasing unreclaimable kernel memory or OOM events when submitting short vhost-net frames.

Typical attack path

1. Obtain local execution on a Linux system, container, VM, or service context with access to TUN/TAP and vhost-net device nodes.
2. Open /dev/net/tun and /dev/vhost-net and configure a TUN/TAP device as a vhost-net backend.
3. Prepare virtio-net TX descriptors where the payload length after the virtio-net header is less than ETH_HLEN.
4. Repeatedly kick the vhost transmit queue with batches of malformed short frames.
5. Trigger the tun_xdp_one() error path that rejects the short frame but fails to release the page-fragment allocation.
6. Continue submissions until leaked kernel memory causes host-wide memory exhaustion, OOM activity, service disruption, panic, or reboot.

How to detect it

Look for evidence of unusual local use of TUN/TAP and vhost-net followed by kernel memory exhaustion. Useful sources include kernel logs, systemd journal, auditd logs, EDR process telemetry, container runtime audit logs, and hypervisor or orchestration logs that record device passthrough. Search for OOM killer messages, kernel panics, sudden reboots, and processes opening /dev/net/tun or /dev/vhost-net repeatedly or unexpectedly. Audit records showing open/openat/ioctl activity against both device nodes by the same process shortly before OOM activity are particularly relevant. For containerized environments, review pod/container specifications and runtime events for device mounts granting access to /dev/net/tun or /dev/vhost-net. There may be no network-visible indicator because exploitation is local and occurs through kernel device interfaces rather than inbound packets.

• /dev/net/tun
• /dev/vhost-net
• Out of memory: Killed process
• oom-killer
• invoked oom-killer
• Kernel panic - not syncing: Out of memory
• page allocation failure
• vhost-net
• tun:
• TUNSETIFF
• openat(AT_FDCWD, "/dev/net/tun"
• openat(AT_FDCWD, "/dev/vhost-net"
• /var/log/kern.log
• /var/log/messages
• /var/log/syslog
• journalctl -k

What your security team should do

• Prioritize patching Linux hosts that run virtualization, container networking, VPN, network simulation, CI, or multi-tenant workloads where TUN/TAP and vhost-net may be accessible.
• Inventory systems exposing /dev/net/tun and /dev/vhost-net, especially where those devices are mounted or passed into containers, VMs, or untrusted service sandboxes.
• Restrict device-node access using Unix permissions, device cgroups, SELinux/AppArmor profiles, and container runtime policies until all affected kernels are updated.
• Monitor for OOM killer activity, kernel memory pressure, and suspicious local processes repeatedly opening /dev/net/tun or /dev/vhost-net.
• After patching, verify that hosts have rebooted into the fixed kernel and remove any temporary broad device access granted during troubleshooting or application deployment.
• Treat unexpected OOM events on systems exposing vhost-net/TUN as potentially suspicious, even though public exploitation maturity is currently reported as none and EPSS is low.