A flaw found in the Linux Kernel. The tun/tap sockets have their socket UID hardcoded to 0 due to a type confusion in their initialization function. While it will be often correct, as tuntap devices require CAP_NET_ADMIN, it may not always be the case, e.g., a non-root user only having that capability. This would make tun/tap sockets being incorrectly treated in filtering/routing decisions, possibly bypassing network filters. References: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=66b2c338adce580dfce2199591e65e2bab889cff https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=a096ccca6e503a5c575717ff8a36ace27510ab0a
Created kernel tracking bugs for this issue: Affects: fedora-all [bug 2212180]
This was fixed for Fedora with the 6.1.16 stable kernel updates.
[PATCH 0/2] tun/tap: set sk_uid from current_fsuid() Message-Id: <20230731164237.48365-1-lersek> https://lore.kernel.org/all/20230731164237.48365-1-lersek@redhat.com/
This issue has been addressed in the following products: Red Hat Enterprise Linux 9 Via RHSA-2023:6583 https://access.redhat.com/errata/RHSA-2023:6583