CVE-2026-52940

What it actually does

This is a local Linux kernel information disclosure in the TUN/TAP networking driver. When tun_put_user() builds a virtio network header for a non-tunnel packet, only the first 10 bytes are initialized, but an unprivileged caller can request a 24-byte vnet header with TUNSETVNETHDRSZ. The kernel then copies the full 24-byte stack object back to userspace, leaking 14 bytes of uninitialized kernel stack data per packet read. The flaw does not directly provide code execution or privilege escalation, but repeated leaks may expose kernel pointers or adjacent stack data that could assist other exploitation techniques such as kernel address disclosure or mitigation bypass.

Why it matters to the business

The main risk is unauthorized disclosure of small amounts of kernel memory from Linux systems using TUN/TAP networking, especially virtualization, VPN, container, network-emulation, and multi-tenant workloads. On its own, this issue is unlikely to cause immediate service outage or direct compromise, and the current EPSS is low with no CISA KEV listing or known exploit maturity reported. However, on shared Linux infrastructure, even small kernel memory leaks can reduce exploit resistance and may become more important when chained with another local kernel vulnerability.

How an attack unfolds

An attacker first needs local code execution or the ability to interact with a TUN/TAP device. They open or obtain access to /dev/net/tun, configure a TUN/TAP interface or compatible file descriptor, and use the TUNSETVNETHDRSZ ioctl to request a 24-byte virtio network header. The attacker then causes or waits for non-tunnel packets to be delivered through the interface and reads from the TUN/TAP device. During each read, the vulnerable kernel path initializes only the base virtio_net_hdr portion of an on-stack structure and copies the larger requested header back to the attacker-controlled userspace buffer. Bytes 10 through 23 contain residual kernel stack contents. By repeating the operation, the attacker can collect multiple small leaks and analyze them for pointers, stack values, or other sensitive data that may help defeat kernel hardening or support a separate local privilege-escalation exploit.

How to fix it

Upgrade to a kernel version from the relevant Linux distribution or kernel vendor that includes the fix to zero the full virtio_net_hdr_v1_hash_tunnel structure in tun_put_user(). Because no exact fixed package versions were provided, rely on vendor security advisories and kernel changelogs for CVE-2026-52940 or the TUN/TAP fix titled "tun: zero the whole vnet header in tun_put_user()". After installing the fixed kernel, reboot affected systems or otherwise ensure the patched kernel is running. Where immediate patching is not possible, reduce exposure by restricting access to /dev/net/tun, limiting CAP_NET_ADMIN and unprivileged user namespaces, avoiding unnecessary TUN/TAP device passthrough into containers, and using seccomp or container runtime policy to block unnecessary TUN/TAP ioctls where operationally feasible.

How to confirm the fix worked

Confirm that the running kernel, not only the installed package, contains the vendor fix. Validate with uname -a, package manager kernel version checks, distribution security advisories, or source verification showing that tun_put_user() zeroes the entire vnet header structure before use. Reboot validation is important because a patched kernel package does not protect the system until it is running. Also review whether untrusted users, containers, or workloads can access /dev/net/tun or create TUN/TAP devices. If testing in a lab, a reproducer should no longer receive nonzero residual data in the extended vnet header bytes for non-tunnel packets after setting TUNSETVNETHDRSZ to 24.

Typical attack path

1. Gain local execution on a Linux system or within an environment that permits access to TUN/TAP functionality.
2. Open or obtain a file descriptor for /dev/net/tun.
3. Configure the TUN/TAP device and set the vnet header size to 24 bytes using the TUNSETVNETHDRSZ ioctl.
4. Generate, route, or wait for non-tunnel packets to be readable through the TUN/TAP interface.
5. Read packets from the TUN/TAP file descriptor and capture the returned virtio network header bytes.
6. Extract the uninitialized bytes from offsets 10 through 23 of the returned header.
7. Repeat reads to accumulate leaked kernel stack data and use it to aid further exploitation or bypass memory-layout protections.

How to detect it

Successful exploitation is difficult to prove after the fact because the leak occurs through normal read operations and does not necessarily create kernel errors, files, crashes, or network-visible signatures. Focus on telemetry showing unexpected local interaction with TUN/TAP devices. Useful sources include Linux auditd syscall logs, EDR process/file/device telemetry, container runtime logs, seccomp denials, kernel audit records, and shell/process history where available. Look for untrusted or unusual processes opening /dev/net/tun, issuing TUNSETVNETHDRSZ with a 24-byte header size, creating transient TUN/TAP interfaces, or repeatedly reading from TUN/TAP file descriptors. In containerized environments, review workloads granted /dev/net/tun, CAP_NET_ADMIN, or privileged mode shortly before suspicious activity. Because there are no known public exploit indicators or KEV-listed exploitation, absence of these events should not be treated as definitive proof of non-exploitation unless syscall/device telemetry was collected at the time.

• /dev/net/tun
• TUNSETVNETHDRSZ
• TUNSETVNETHDRSZ, 24
• ioctl(.*, TUNSETVNETHDRSZ, 24)
• tun_put_user
• virtio_net_hdr_v1_hash_tunnel
• CAP_NET_ADMIN
• IFF_TUN
• IFF_TAP

What your security team should do

• Prioritize patching shared, multi-tenant, container-hosting, VPN, virtualization, CI/CD runner, and network appliance Linux systems where untrusted workloads may access TUN/TAP functionality.
• Verify that patched kernels are actively running after maintenance windows; do not rely only on package installation status.
• Restrict /dev/net/tun exposure to only workloads that require it, especially in containers and sandboxed environments.
• Limit CAP_NET_ADMIN, unprivileged user namespaces, and container device passthrough that could allow untrusted users to exercise TUN/TAP ioctls.
• Add audit or EDR monitoring for unusual /dev/net/tun access and TUNSETVNETHDRSZ usage by unexpected processes or users.
• Treat this primarily as a confidentiality and exploit-chain hardening issue; investigate more aggressively if found alongside other local kernel exploit activity.