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. The original fix for the CVE-2023-1076 was incorrect. The problem is that the following upstream commits (that were fix for the CVE-2023-1076) - a096ccca6e50 ("tun: tun_chr_open(): correctly initialize socket uid"), - 66b2c338adce ("tap: tap_open(): correctly initialize socket uid"), pass "inode->i_uid" to sock_init_data_uid() as the last parameter and that turns out to be entirely bogus. References: https://lore.kernel.org/all/20230731164237.48365-1-lersek@redhat.com/ https://lore.kernel.org/all/20230731164237.48365-2-lersek@redhat.com/ https://lore.kernel.org/all/20230731164237.48365-3-lersek@redhat.com/
Created kernel tracking bugs for this issue: Affects: fedora-all [bug 2229499]
Upstream patches: #1 9bc3047374d5 ("net: tun_chr_open(): set sk_uid from current_fsuid()", 2023-08-02) #2 5c9241f3ceab ("net: tap_open(): set sk_uid from current_fsuid()", 2023-08-02)
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