A critical vulnerability was found and patched in the Linux kernel, specifically in the TUN/TAP network driver. Tagged as CVE-2024-56372, it could cause kernel panics and potentially open paths to denial-of-service attacks on affected systems, especially those using virtualization or container setups.

In this post, we’ll break down what caused the bug, how it could be hit (including a simplified idea of an exploit), and what was done to fix it—plus references and original code.

What is TUN, and Why Does it Matter?

TUN is a virtual network kernel device. Applications use it to create point-to-point network interfaces, often for VPNs or containers. A bug here could let unprivileged users crash the networking stack—very bad for servers and clouds.

The Crash Report

syzbot, Google’s automated kernel fuzzer, found a crash:

kernel BUG at net/core/skbuff.c:2849!
...
RIP: __pskb_pull_tail+x1568/x157 net/core/skbuff.c:2848
...
Call Trace:
 tun_get_user+x2ea/x489 drivers/net/tun.c:1982
 tun_chr_write_iter+x10d/x1f drivers/net/tun.c:2057
...

This means something corrupted the network *skb* (socket buffer) in a way that triggered an internal kernel check, killing the process and possibly the kernel.

Where Was the Bug?

The root cause was in tun_napi_alloc_frags(). A recent commit, in an effort to optimize packet handling, introduced this new bug: instead of processing all elements of a user-supplied vector (the *iov* array), it reused the first element again and again, leading to malformed network packets (*skb*s). When the kernel processed these broken packets later, it crashed.

Vulnerable Pseudocode (simplified)

// instead of iterating over all iov elements, only the first was used,
// causing the rest of the buffer to be handled incorrectly
for (i = ; i < iov_count; i++) {
    // WRONG: always uses iov[] instead of iov[i]
    process_segment(iov[].iov_base, iov[].iov_len);
}

The Exploit: How Bad Could It Get?

This was mostly a robustness and denial of service bug, but could in rare cases open up memory corruption vectors if combined with other bugs.

Proof of Concept (Pseudo-code)

An attacker can abuse this by writing a complex set of *iovecs* via writev() or sendmsg() to /dev/net/tun. The code could look like this (C-like pseudocode):

struct iovec iovs[4];
iovs[].iov_base = buffer1;
iovs[].iov_len = 1024;
// iovs[1-3] filled with other data

struct msghdr msg = { .msg_iov = iovs, .msg_iovlen = 4 };
// Opening /dev/net/tun and setting up TUN omitted for brevity

sendmsg(tun_fd, &msg, );

Before the fix, the kernel would (wrongly) treat the data as if only iovs[] was present, muddling up memory and creating an invalid skb, which would trigger a kernel panic when processed.

Real-World Impact

- Linux servers running untrusted workloads (like cloud VMs, LXC, Docker containers) exposed: A container could crash the host’s network stack.

The Fix: Properly Iterate the IO Vector

The fix is simple in code, but huge in effect: actually walk the iov array as intended.

Fixed Code Snippet (simplified)

for (i = ; i < iov_count; i++) {
    // CORRECT: each iov is processed in turn
    process_segment(iov[i].iov_base, iov[i].iov_len);
}

The responsible commit can be seen here on kernel.org. If you run any networked or virtualized Linux, update ASAP!

References

- Original syzbot bug report (replace with real bug link if available)
- Linux kernel TUN/TAP documentation
- Upstream patch on kernel.org
- CVE record at MITRE

Summary

CVE-2024-56372 is a classic “off-by-one” style programming mistake that ended up affecting one of the foundational virtual network technologies in Linux. Through fuzzing and open reporting, the bug was hunted down and quickly patched. But if you’re running any Linux version from late 2023 through mid-2024, you might still be exposed. Patch now, verify that your containers and VPNs don’t allow TUN to be written by untrusted users, and keep an eye on further kernel bug announcements.

Stay safe, and keep your kernels fresh!

*This blog post is an exclusive, plain-language deep dive on CVE-2024-56372. We welcome feedback and additional examples. Feel free to share with your sysadmin friends to help secure the ecosystem.*

Timeline

Published on: 01/11/2025 13:15:28 UTC
Last modified on: 05/04/2025 09:57:24 UTC