netdev - BUG: sock_init_data() assumes socket is embedded in socket

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <5cc30771-f16b-1444-0b31-91ca02796b9a@tycho.nsa.gov>
Date:   Thu, 6 Feb 2020 09:34:37 -0500
From:   Stephen Smalley <sds@...ho.nsa.gov>
To:     "David S. Miller" <davem@...emloft.net>
Cc:     lorenzo@...gle.com, amade@...blr.net,
        Linux Kernel Network Developers <netdev@...r.kernel.org>,
        maxk@....qualcomm.com
Subject: BUG: sock_init_data() assumes socket is embedded in socket_alloc,
 tun/tap does not

Since commit 86741ec25462e4c8cdce6df2f41ead05568c7d5e ("net: core: Add a 
UID field to struct sock.") circa v4.10, sock_init_data() dereferences 
SOCK_INODE(sock) whenever sock is non-NULL, thereby requiring all 
callers that provide a socket to have embedded it within a struct 
socket_alloc.  However, the tun and tap drivers embed a struct socket 
within their own data structures (tun_file and tap_queue), call 
sock_init_data() on these sockets, and were not updated to wrap these 
sockets within socket_alloc. I haven't checked whether there may be 
other cases beyond tun/tap.  A bug report with RFC patches was posted by 
amade@...blr.net back in September to address the tun/tap case here:
https://lore.kernel.org/netdev/20190929110502.2284-1-amade@asmblr.net/ 
seemingly without any response or follow-up that I could see in the 
archives.

Is sock_init_data() wrong to make this assumption, and if so, how should 
it be fixed?  Or should tun/tap and any other callers be updated to 
embed their sockets within socket_alloc structures?  Or should they not 
call sock_init_data() on their sockets?

Sorry if this has been discussed elsewhere but I couldn't find anything 
beyond what I cited above.