A security vulnerability tracked as CVE-2023-4194 has been discovered in the Linux kernel's TUN/TAP functionality. This flaw can let a local user bypass network filters, potentially leading to unauthorized network access and a security mess, especially in containerized environments and systems running untrusted code.

Below, we break down the bug, show you the code, explain the root cause, and illustrate how it can be exploited. We also link you to original sources and provide extra context that goes beyond regular advisories.


## What’s TUN/TAP in Linux?

TUN and TAP are virtual network kernel devices.

TAP (network tap) simulates a layer 2 device (Ethernet frames).

Programs can use these devices to send/receive packets, which is vital for things like VPNs or container networking. Security-wise, it's important to reliably identify *who* owns the socket, so the kernel can apply the correct network filters.

The Flawed Patch Origin

The vulnerability is directly related to previous security hardening done for CVE-2023-1076. Upstream tried to fix a privilege confusion by passing the inode owner’s UID to the socket logic in the TUN/TAP initialization. Here are the relevant (buggy) commits:

- a096ccca6e50 (tun: tun_chr_open(): correctly initialize socket uid)
- 66b2c338adce (tap: tap_open(): correctly initialize socket uid)

Both pass inode->i_uid as the argument for the *socket UID* when they call sock_init_data_uid() — but it's not always the right thing to do.

The Mistake Explained

When a process opens /dev/net/tun or /dev/tap via open(2), the inode->i_uid field reflects the filesystem owner of the device node, *not* the calling user's actual credentials.

This means that the socket associated with TUN/TAP ends up being run with the device node’s owner UID, not necessarily the caller. This opens several attack vectors:

Attack Scenarios

- *Local unprivileged users* open a device file owned by root (or another user), and then their TUN/TAP sockets are created as if owned by that user.
- If access control (e.g., cgroups, eBPF, iptables owner match) is keyed off the socket UID, these filters can be bypassed.
- In container or VM setups (such as OpenVZ/LXC), malicious users may escape networking restrictions.

Here’s a simplified snippet from the Linux kernel that shows the vulnerable logic

// from drivers/net/tun.c

static int tun_chr_open(struct inode *inode, struct file *file)
{
    ...
    struct socket *sock;
    ...
    // This is the problematic line:
    sock_init_data_uid(inode, file, &sock, inode->i_uid);
    ...
}

The correct way is to pass the real user's UID, not the device node's

sock_init_data_uid(inode, file, &sock, current_fsuid());

Minimal Proof-of-Concept (Pseudo-code)

If /dev/net/tun is owned by root,
1. Unprivileged user calls open("/dev/net/tun", ...) and ioctl(TUNSETIFF, ...)

TUN socket gets initialized *with UID * due to the bug.

3. User can then craft packets or set up routes/bpf/iptables that match root-owned sockets.

They bypass user-based filtering or monitoring.

Practical impact: On systems with user-based filtering, the attacking user gets unwanted privileges on the network stack.

Who is Vulnerable?

- Distributions: All major distros that shipped the buggy patch between CVE-2023-1076 and the real fix for CVE-2023-4194.
- Environments: Multi-user servers, containers, VPS hosting, any system where /dev/net/tun is accessible and network filters are enforced by socket UID.

References

- CVE-2023-4194 @ Red Hat
- Upstream Linux commit a096ccca6e50
- Upstream Linux commit 66b2c338adce
- CVE-2023-1076 (the earlier, related flaw)
- oss-sec mailing list discussion

What To Do

- Update your kernel to a version that has the fixed patch (Check your distribution's advisories for CVE-2023-4194).
- Restrict access to /dev/net/tun and /dev/tap to trusted users and processes.
- Audit your containers and VMs for any capability to open /dev/net/tun directly.

Summary

CVE-2023-4194 reminds us that subtle bugs — like picking the wrong UID — can have big security consequences. This issue is especially important in modern, multi-tenant environments. Make sure your systems got the *real* fix, not the incomplete one!

Timeline

Published on: 08/07/2023 14:15:00 UTC
Last modified on: 08/19/2023 18:17:00 UTC