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  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]
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.

Powered by blists - more mailing lists