CVE-2026-46322: tun: free page on build_skb failure in tun_xdp_one()
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.
Metrics
- CVSS v3.1
- 7.1
- Severity
- HIGH
- Fixed in
- 0
- Affected Products
- 2
HarborGuard Analysis
Synopsis
A memory leak vulnerability exists in the Linux kernel's TUN/TAP network driver, specifically in the tun_xdp_one() function. The bug is reachable locally without any authentication: when build_skb() fails due to memory pressure, the function exits without freeing a previously allocated page fragment, leaking memory on every occurrence. Repeated build_skb() failures in a batch silently exhaust kernel memory, disrupting or crashing the affected service. Patched-image rebuilds are available on HarborGuard for environments running affected kernel versions, including 6.12.93, 6.18.35, and 7.0.12.
HarborGuard Coverage
Detection of CVE-2026-46322 is available across every HarborGuard environment; the CVE is ingested from upstream feeds within minutes of publication and matched against images in customer registries, CI/CD pipelines, and custom-built images that bundle an affected Linux kernel version.
AvailableHarborGuard is capable of scoring this CVE at CVSS 7.1 (HIGH) and applying per-environment compliance policy weighting to determine urgency and escalation path, routing findings to the appropriate team inbox within each customer organization.
AvailableA patched-image rebuild at the fix versions (6.12.93, 6.18.35, or 7.0.12 as appropriate) becomes available on HarborGuard once the upstream fix is confirmed. For customers who opt into auto-remediation, HarborGuard can perform the rebuild, run a regression test suite, and open a pull request against affected workloads automatically.
AvailableExploit Conditions
- Network reachabilityNot required
The attacker needs an existing shell or process on the host; no network path to the target is required.
- AuthenticationNot required
No credentials or account are required to trigger the vulnerable code path.
- Victim interactionNot required
No user action or social engineering is needed; the attacker can trigger the bug independently.
- Attack complexityDetail
The exploit is reliable and condition-free once local access is established; no race conditions or special memory layout is required.
Blast Radius
- Repeated build_skb() failures in a batch cause the kernel to leak one page-fragment chunk per failure, steadily consuming kernel memory.
- Sustained memory exhaustion degrades or fully disrupts TUN/TAP-backed network I/O on the affected host.
- Workloads depending on virtual network interfaces (containers, VMs, VPN tunnels) may lose connectivity or crash as kernel memory is depleted.
How HarborGuard Handles This
Available on HarborGuard: images bundling an affected Linux kernel version are flagged automatically upon ingestion, with CVSS 7.1 HIGH severity applied and compliance-policy weighting used to prioritize the finding. Where auto-remediation is enabled, HarborGuard can rebuild the image at a fixed kernel version (6.12.93, 6.18.35, or 7.0.12 depending on the base image's tracked branch), run a regression test suite against the rebuilt image, and open a pull request against affected workloads. For teams that manage auto-remediation manually, the rebuilt image is available in the HarborGuard catalog as soon as the upstream fix is confirmed. Where an immediate rebuild is not possible, compensating controls such as restricting local access to the host, limiting TUN/TAP device creation to privileged users via Linux capabilities (CAP_NET_ADMIN), and configuring cgroup memory limits to bound the impact of any leak are worth considering while the patch is staged.
Fix available
- Linux / Linux< d16e38fac09a47bfcf98c1ad65a1bb53f94540f5 (from 043d222f93ab8c76b56a3b315cd8692e35affb6c) · < aa308e9dbb9acb17cacdbbce9e4504f69bac8385 (from 043d222f93ab8c76b56a3b315cd8692e35affb6c) · < 4fefc6156a162a9f50035c12091a5e5130c82c6e (from 043d222f93ab8c76b56a3b315cd8692e35affb6c) · < aa8963fdce667a42fb7f0bdd2909fadcab02f9a8 (from 043d222f93ab8c76b56a3b315cd8692e35affb6c)
- Linux / Linux4.20Fixed in 0, 6.12.93, 6.18.35, 7.0.12, 7.1-rc6
CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H