CVE-2026-46320

What it actually does

This Linux kernel flaw is a memory leak in the TAP/vhost networking transmit path, specifically in tap_get_user_xdp(). When a malformed or too-short frame is processed, or when build_skb() fails, memory allocated by vhost_net_build_xdp() is not freed on the error path. Because tap_sendmsg() discards the per-buffer error and reports success, the vhost transmit batching logic does not reclaim the allocation. Repeated triggering can leak page fragments from kernel memory, eventually causing memory pressure and availability degradation. The issue primarily affects availability; it does not directly provide confidentiality or integrity impact.

Why it matters to the business

A local or adjacent attacker with the ability to send crafted traffic through affected TAP/vhost networking paths could cause increasing memory consumption on Linux systems, potentially degrading or interrupting virtual networking workloads and services that depend on them. The highest operational risk is to virtualization, container, network appliance, and multi-tenant infrastructure where TAP/vhost devices are exposed or heavily used. The vulnerability is not currently listed in CISA KEV, has no known public exploit maturity in the supplied data, and has a low EPSS score, so remediation should be prioritized based on exposure of affected kernel networking features and service criticality rather than evidence of widespread exploitation.

How an attack unfolds

An attacker first needs access to a path that can submit frames into an affected TAP/vhost network interface, such as through a virtualized or locally reachable networking configuration. They then repeatedly send frames that cause tap_get_user_xdp() to take an error path, such as frames shorter than the Ethernet header length, or induce allocation/build failures under pressure. Each rejected frame can leave a page-frag allocation unreleased because the surrounding send and batching logic treats the operation as successful. Over time, repeated triggering consumes kernel memory, causing memory pressure, packet loss, workload instability, service degradation, or host-level denial of service. The issue is a resource-exhaustion condition rather than a code execution primitive.

How to fix it

Upgrade the Linux kernel to a vendor or distribution release that includes the upstream fix for the TAP tap_get_user_xdp() error-path page-freeing issue. Because no exact affected products or fixed versions were supplied, use the relevant Linux distribution security advisories and kernel changelogs to identify the first fixed package for each deployed kernel stream. Where immediate patching is not possible, reduce exposure by limiting untrusted access to TAP/vhost networking devices, restricting VM/container networking operations to trusted users, applying least privilege to workloads that can create or use TAP devices, and monitoring/limiting memory consumption for hosts running virtual networking workloads. Reboots may be required after kernel package updates to ensure the fixed kernel is active.

How to confirm the fix worked

Confirm remediation by verifying that systems are running a kernel build containing the patch that frees the allocated page on tap_get_user_xdp() error paths. Validate the active runtime kernel, not only the installed package, using standard OS inventory and uname/package-manager checks. Review vendor advisories for the deployed distribution to confirm the running kernel version is fixed. In exposed environments, perform controlled negative testing only in a lab by sending invalid TAP/vhost frames and confirming that kernel memory does not grow continuously. Operationally, validate that virtual networking hosts do not show unexplained memory growth, increasing allocation failures, or network service instability under normal traffic.

Typical attack path

1. Identify a Linux system using TAP/vhost networking paths, commonly associated with virtualization or high-performance virtual networking.
2. Gain the ability to submit traffic or frames through the affected TAP interface or related vhost-net path.
3. Send repeated malformed, undersized, or otherwise error-triggering frames that reach tap_get_user_xdp().
4. Cause the vulnerable error handling path to leak page-frag-backed kernel memory for each rejected frame.
5. Continue the traffic pattern until memory pressure affects networking workloads, virtual machines, containers, or the host itself.
6. Use the resulting instability or outage to disrupt service availability.

How to detect it

Look for evidence of resource-exhaustion behavior on Linux hosts using TAP/vhost networking. Useful log sources include kernel logs, systemd journal, hypervisor logs, QEMU/KVM logs, container runtime logs, network appliance logs, and monitoring telemetry for memory, OOM, and virtual interface errors. Investigate sustained or repeated memory growth correlated with traffic through TAP/vhost interfaces, especially where there are malformed or very short Ethernet frames, packet drops, VM network instability, or unexplained host memory pressure. Search for OOM killer activity, page allocation failures, vhost_net/tap driver warnings, VM or container network resets, and spikes in traffic involving tap*, vnet*, or related virtual interfaces. There are no unique exploitation strings in the vulnerability description, so detection should focus on behavioral indicators: repeated malformed frame handling, rising unreclaimable memory, host memory pressure, and service degradation on virtual networking hosts. If threat hunting for prior exploitation, correlate the first appearance of abnormal memory pressure with workloads or users that had access to TAP/vhost networking paths.

• Out of memory: Killed process
• oom-killer
• invoked oom-killer
• page allocation failure
• Memory allocation failure
• vhost_net
• /dev/net/tun
• tap_get_user_xdp
• tap_sendmsg
• vhost_tx_batch
• build_skb
• tap*
• vnet*

What your security team should do

• Inventory Linux systems using TAP, vhost-net, KVM/QEMU, container networking, network virtualization, or other workloads that may exercise the affected code path.
• Prioritize patching hosts that run multi-tenant virtualization, externally exposed network appliances, or critical virtual networking infrastructure.
• Apply vendor kernel updates and reboot into the fixed kernel; confirm the active kernel version after reboot.
• Restrict access to TAP device creation and vhost networking capabilities to trusted administrators and service accounts only.
• Monitor affected hosts for abnormal kernel memory growth, OOM events, vhost/tap-related errors, and virtual network instability until patched.
• Treat exploitation as a denial-of-service risk: prepare operational runbooks for isolating abusive workloads, rate-limiting traffic paths, and restarting impacted hosts if memory exhaustion occurs.
• Because there is no supplied KEV listing, ransomware association, known threat actor use, or mature public exploit, prioritize based on local exposure and criticality rather than emergency internet-wide exploitation assumptions.