CVE-2026-52940: Linux Kernel Information Disclosure Flaw

CVE-2026-52940 Overview

CVE-2026-52940 is an information disclosure vulnerability in the Linux kernel's tun driver. The flaw resides in tun_put_user(), which declares an on-stack struct virtio_net_hdr_v1_hash_tunnel without zeroing it. For non-tunnel skb packets, virtio_net_hdr_tnl_from_skb() only initializes the first 10 bytes, leaving bytes 10 through 23 populated with stack garbage. An unprivileged local user can set the vnet header size to 24 using the TUNSETVNETHDRSZ ioctl, causing __tun_vnet_hdr_put() to copy 14 bytes of uninitialized kernel stack memory to userspace on every read of a non-tunnel packet.

Critical Impact
Unprivileged local users can read 14 bytes of kernel stack memory per non-tunnel packet, enabling reconnaissance of kernel addresses and secrets that aid further exploitation.

Affected Products

Linux kernel versions containing the virtio_net_hdr_v1_hash_tunnel structure in the tun driver
Distributions shipping the affected tun_put_user() implementation prior to upstream fix commits 585cb85, 5fd1fa5, and 7f2fcff
Systems where unprivileged users can open /dev/net/tun (containers, virtualization hosts, VPN clients)

Discovery Timeline

2026-06-24 - CVE-2026-52940 published to NVD
2026-06-24 - Last updated in NVD database

Technical Details for CVE-2026-52940

Vulnerability Analysis

The tun (TUN/TAP) driver provides userspace programs with virtual network interfaces. When userspace reads from a tun device, the kernel prepends a virtio_net_hdr describing packet metadata. The TUNSETVNETHDRSZ ioctl allows an unprivileged user to choose the size of this header, up to 24 bytes for the extended virtio_net_hdr_v1_hash_tunnel variant. The vulnerability is classified as Uninitialized Memory Use [CWE-908] and Information Exposure [CWE-200].

The defect occurs because tun_put_user() allocates the header structure on the kernel stack without calling memset() to clear it. When the outgoing skb is not a tunneled packet, the helper function virtio_net_hdr_tnl_from_skb() only writes the first 10 bytes corresponding to the base struct virtio_net_hdr. The remaining 14 bytes covering num_buffers and the hash and tunnel fields retain whatever data previously occupied that stack region.

Root Cause

The root cause is missing zero-initialization of an on-stack structure before partial population. The sibling function tun_get_user() already zeroes the entire header after declaration, but tun_put_user() omitted this step. When __tun_vnet_hdr_put() subsequently copies the full 24-byte structure to userspace through copy_to_iter(), the uninitialized tail bytes leak to the reader.

Attack Vector

An unprivileged local attacker with access to /dev/net/tun opens a tun device, issues the TUNSETVNETHDRSZ ioctl to set the vnet header size to 24, and reads packets from the device. Each read of a non-tunnel packet returns 14 bytes of kernel stack contents. Repeated reads sample different stack frames and can disclose pointers, canaries, or secrets useful for defeating Kernel Address Space Layout Randomization (KASLR) or chaining further exploits. The vulnerability does not require root privileges in environments where users can create tun interfaces, including many container and VPN configurations.

No public proof-of-concept code is available. The upstream patches 585cb85, 5fd1fa5, and 7f2fcff resolve the issue by zeroing the full header immediately after declaration, matching the existing pattern in tun_get_user().

Detection Methods for CVE-2026-52940

Indicators of Compromise

Unexpected processes opening /dev/net/tun without legitimate VPN, container, or virtualization workloads
Userspace programs invoking TUNSETVNETHDRSZ with a value of 24 followed by sustained read loops
Anomalous ioctl() activity on tun file descriptors originating from unprivileged UIDs

Detection Strategies

Audit openat() syscalls targeting /dev/net/tun using auditd rules and correlate with the invoking UID and binary path
Monitor for the TUNSETVNETHDRSZ ioctl (0x400454d8) issued by non-system accounts
Hunt for processes that combine tun device access with tight read loops and minimal network output, indicating leakage harvesting

Monitoring Recommendations

Enable kernel lockdown or restrict CAP_NET_ADMIN to limit who can create tun interfaces
Forward auditd and eBPF telemetry to a centralized analytics platform for behavioral baselining of network device access
Track kernel package versions across the fleet and alert when hosts fall behind the stable releases containing commits 585cb85, 5fd1fa5, or 7f2fcff

How to Mitigate CVE-2026-52940

Immediate Actions Required

Apply the upstream kernel patches 585cb85e9a29185be05f326369573c2663cf4380, 5fd1fa5a4254bfdd70571c77f5e3bcb4e43738d5, and 7f2fcff15e99bb852f6967396ed12b38376e2c8d or upgrade to a distribution kernel containing the backport
Inventory hosts that expose /dev/net/tun to unprivileged users, including container hosts and multi-tenant systems
Restrict tun device creation to trusted accounts until patched kernels are deployed

Patch Information

The fix zeroes the entire struct virtio_net_hdr_v1_hash_tunnel immediately after its declaration in tun_put_user(), matching the existing behavior in tun_get_user(). Refer to the upstream commits Kernel Git Commit 585cb85, Kernel Git Commit 5fd1fa5, and Kernel Git Commit 7f2fcff for the source-level changes and applicable stable branches.

Workarounds

Remove the tun kernel module on systems that do not require virtual network interfaces using modprobe -r tun and blacklist it in /etc/modprobe.d/
Tighten permissions on /dev/net/tun so only privileged service accounts can open it
Drop CAP_NET_ADMIN from unprivileged container profiles and seccomp-filter the TUNSETVNETHDRSZ ioctl where feasible

bash

# Restrict tun device access until patched kernel is deployed
chown root:root /dev/net/tun
chmod 0600 /dev/net/tun

# Blacklist the tun module on hosts that do not need it
echo 'install tun /bin/true' > /etc/modprobe.d/disable-tun.conf