In June 2024, the cybersecurity community became aware of a newly-resolved vulnerability affecting the Linux kernel's TAP virtual network interface driver. Assigned CVE-2024-41090, this bug could potentially allow attackers to inject malformed network frames, leading to memory corruption or unpredictable networking stack behavior.

Below, we’ll break down what this issue was, how it’s exploitable, what’s been fixed, and how you can protect your systems.

First, a quick primer

- TAP devices are software-only network devices in Linux used to read and inject Ethernet frames at the OS kernel level.
- Programs (like virtual machines or containers) use TAP devices for custom network traffic processing.

What Went Wrong? (Technical Details)

The issue was rooted in the kernel's TAP driver's tap_get_user_xdp() function. This function pulls packets from user space, wraps them in a structure known as skb (socket buffer), and sends them into the kernel's networking stack.

The vulnerable code missed a length check: it did not verify if the frame was at least as large as a standard Ethernet header (ETH_HLEN, i.e., 14 bytes). This could allow a bad actor to send under-sized (or “short”) frames.

Why is this a problem?
- Functions further down the stack (like skb_set_network_header()) expect the frame to contain a valid Ethernet header.
- If the frame is too short, these functions could read past the actual data—causing out-of-bounds memory access. This creates risks of memory corruption or even denial of service.

Alternatively, the stack could become confused over inconsistent metadata. Yikes!

The tap_get_user() function (an alternative packet input path) did check for short frames, so it was only tap_get_user_xdp() that was affected.

Here’s a simplified version of what was missing

// Before the patch: tap_get_user_xdp() did not reject short frames
int tap_get_user_xdp(...) {
    ...
    // No check for frame length!
}

After the patch, the length is checked (see commit 9b356e3b7ba):

// After the patch: drops any frame smaller than ETH_HLEN (14 bytes)
int tap_get_user_xdp(...) {
    ...
    if (frame_len < ETH_HLEN) {
        // Reject and drop the frame!
        return -EINVAL;
    }
    ...
}

How Could an Attacker Use This?

If an untrusted user or process can send traffic to a TAP interface (for example, inside a container or a VM), they could craft a frame like:

# Send intentionally short (malformed) Ethernet frame via the tap device
short_frame = b'\x00' * 10  # Less than 14 bytes
tap_fd = open('/dev/tap', 'wb')
tap_fd.write(short_frame)   # Kernel will process this if unpatched

On an unpatched kernel, this could corrupt memory, risking a crash or even code execution (depending on kernel configuration and mitigations).

Any Linux system using TAP interfaces with kernels before the patch.

- Those who allow untrusted processes to interact with TAP devices (common in virtualization/container environments).

Most typical desktop/server users not dealing with custom network setups are less likely to be affected.

What Should You Do?

1. Update your kernel. The bug was patched in commit 9b356e3b7ba, merged shortly after the public report.
2. Restrict user access to TAP devices. Only trusted users and services should be able to open and use /dev/net/tun or /dev/tap*.

References

- Patch commit on kernel.org
- Official CVE Entry: CVE-2024-41090
- Linux Kernel TAP Driver

Conclusion

CVE-2024-41090 underscores the importance of basic input validation inside the Linux kernel. One missing check could allow injection of malformed network frames, possibly leading to memory corruption or denial of service. If you use TAP devices, update your kernel as soon as you can!

Timeline

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