OSDN Git Service

Merge branch 'tuntap-socket-uid'
authorDavid S. Miller <davem@davemloft.net>
Mon, 6 Feb 2023 10:16:55 +0000 (10:16 +0000)
committerDavid S. Miller <davem@davemloft.net>
Mon, 6 Feb 2023 10:16:55 +0000 (10:16 +0000)
commitc21adf256f8dcfbc07436d45be4ba2edf7a6f463
treedb2d69568ee3cbce31d03565f18468eb6f63f628
parentb601135e8d704f3218efaf07cdb2ebf310aedc2a
parent66b2c338adce580dfce2199591e65e2bab889cff
Merge branch 'tuntap-socket-uid'

Pietro Borrello says:

====================
tuntap: correctly initialize socket 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 tuntap 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 tuntap sockets may
be incorrectly managed.
Additionally, it seems a socket with an incorrect uid may be returned
to the vhost driver when issuing a get_socket() on a tuntap device in
vhost_net_set_backend().

Fix the bugs by adding and using sock_init_data_uid(), which
explicitly takes a uid as argument.

Signed-off-by: Pietro Borrello <borrello@diag.uniroma1.it>
---
Changes in v3:
- Fix the bug by defining and using sock_init_data_uid()
- Link to v2: https://lore.kernel.org/r/20230131-tuntap-sk-uid-v2-0-29ec15592813@diag.uniroma1.it

Changes in v2:
- Shorten and format comments
- Link to v1: https://lore.kernel.org/r/20230131-tuntap-sk-uid-v1-0-af4f9f40979d@diag.uniroma1.it
====================

Signed-off-by: David S. Miller <davem@davemloft.net>