Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [day] [month] [year] [list]
Date: Wed, 1 Mar 2023 16:13:11 +0100
From: Pietro Borrello <>
Subject: CVE-2023-1076: Linux Kernel: Type Confusion hardcodes tuntap socket
 UID to root

Hi all,

I am disclosing a type confusion in the initialization of TUN/TAP sockets
which hardcodes their UID to 0, usually the root UID.
sock_init_data() assumes that the `struct socket` passed in input is
contained in a `struct socket_alloc` allocated with sock_alloc().
However, tap_open() and tun_chr_open() pass a `struct socket` embedded
in a `struct tap_queue` and `struct tun_file` respectively, both
allocated with sk_alloc().
This causes a type confusion when issuing a container_of() with
SOCK_INODE() in sock_init_data() which results in assigning a wrong
sk_uid to the `struct sock` in input.

Due to the type confusion, both sockets happen to have their UID set
to 0, i.e. root.
While it will be often correct, as TUN/TAP devices require
CAP_NET_ADMIN, it may not always be the case.
Not sure how widespread is the impact of this, it seems the socket UID
may be used for network filtering and routing, thus TUN/TAP sockets may
be incorrectly managed, potentially bypassing network filters based on UID.
Additionally, it seems the sockets with an incorrect UID may be returned
to the vhost driver when issuing a get_socket() on a TUN/TAP device in

The proposed patches fix the bugs by adding and using sock_init_data_uid(),
which explicitly takes a UID as argument, and have been merged:

The issue has been assigned CVE-2023-1076.

Best regards,
Pietro Borrello

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.