netdev - [RFC] SIOCGSTAMP semantics

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>] [day] [month] [year] [list]

Message-ID: <20171013205438.GJ21978@ZenIV.linux.org.uk>
Date:   Fri, 13 Oct 2017 21:54:38 +0100
From:   Al Viro <viro@...IV.linux.org.uk>
To:     netdev@...r.kernel.org
Subject: [RFC] SIOCGSTAMP semantics

	ioctl() in question
1) fails with EOPNOTSUPP on
	AF_ALG, AF_CAIF, AF_IUCV, AF_KEY, AF_NFC, AF_RXRPC, AF_VSOCK
2) fails with ENOTTY on
	AF_DECnet, AF_KCM, AF_LLC, AF_NETLINK, AF_PHONET, AF_PPPOX, AF_RDS,
	AF_TIPC, AF_UNIX
3) fails with EINVAL on
	AF_ISDN
4) sock_get_timestamp(sock->sk, arg)
	AF_INET, AF_INET6, AF_CAN, AF_ROSE, AF_PACKET, AF_IEEE802154,
	AF_ATMSVC, AF_ATMPVC, AF_APPLETALK
5) sock_get_timestamp(sock->sk, arg) under lock_sock(sock->sk)
	AF_AX25, AF_NETROM, AF_QRTR, AF_IPX
6) sock_get_timestamp(sock->sk, arg) after checking that sock->sk != NULL
	AF_X25, AF_IRDA

AF_BLUETOOTH is sometimes (1), sometimes (2), sometimes (4).  Not sure about
AF_SMC - sometimes it's (1), sometimes might be (4).

To make the things even less consistent, AF_CAN, AF_IPX and AF_QRTR lack
SIOCGSTAMPNS; everything else has it parallel to SIOCGSTAMP with s/timestamp/&ns/.

Am I right assuming that (5) and (6) should be like (4)?  IOW, that
lock_sock() is not needed for anyone and that sock->sk cannot be NULL on
anything that could be fed to ioctl()?  If the last assumption is not true,
we have a plenty of triggerable oopsen - other ioctls (handled on the top
level) do _not_ check that and dereference sock->sk directly.  I've grepped
around, and AFAICS NULL sock->sk on an opened socket should be impossible,
but confirmation would be nice.

Another question, of course, is whether anyone gives a damn about distinctions
between (1), (2) and (3) *and* if anything bad would've happenend from having
sock_get_timestamp() simply done to all sockets, right in net/socket.c.

Comments?