netdev - net/core/sock.c lacks some SO_TIMESTAMPING

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

Date: Mon, 18 Dec 2023 22:28:47 +0100
From: Thomas Lange <thomas@...elatus.se>
To: netdev@...r.kernel.org
Subject: net/core/sock.c lacks some SO_TIMESTAMPING_NEW support

It seems that net/core/sock.c is missing support for SO_TIMESTAMPING_NEW in
some paths.

I cross compile for a 32bit ARM system using Yocto 4.3.1, which seems to have
64bit time by default. This maps SO_TIMESTAMPING to SO_TIMESTAMPING_NEW which
is expected AFAIK.

However, this breaks my application (Chrony) that sends SO_TIMESTAMPING as
a cmsg:

sendmsg(4, {msg_name={sa_family=AF_INET, sin_port=htons(123), sin_addr=inet_addr("172.16.11.22")}, msg_namelen=16, msg_iov=[{iov_base="#\0\6 \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., iov_len=48}], msg_iovlen=1, msg_control=[{cmsg_len=16, cmsg_level=SOL_SOCKET, cmsg_type=SO_TIMESTAMPING_NEW, cmsg_data=???}], msg_controllen=16, msg_flags=0}, 0) = -1 EINVAL (Invalid argument)

This is because __sock_cmsg_send() does not support SO_TIMESTAMPING_NEW as-is.

This patch seems to fix things and the packet is transmitted:

diff --git a/net/core/sock.c b/net/core/sock.c
index 16584e2dd648..a56ec1d492c9 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -2821,6 +2821,7 @@ int __sock_cmsg_send(struct sock *sk, struct cmsghdr *cmsg,
                 sockc->mark = *(u32 *)CMSG_DATA(cmsg);
                 break;
         case SO_TIMESTAMPING_OLD:
+       case SO_TIMESTAMPING_NEW:
                 if (cmsg->cmsg_len != CMSG_LEN(sizeof(u32)))
                         return -EINVAL;

However, looking through the module, it seems that sk_getsockopt() has no
support for SO_TIMESTAMPING_NEW either, but sk_setsockopt() has.
Testing seems to confirm this:

setsockopt(4, SOL_SOCKET, SO_TIMESTAMPING_NEW, [1048], 4) = 0
getsockopt(4, SOL_SOCKET, SO_TIMESTAMPING_NEW, 0x7ed5db20, [4]) = -1 ENOPROTOOPT (Protocol not available)

Patching sk_getsockopt() is not as obvious to me though.

I used a custom 6.6 kernel for my tests.
The relevant code seems unchanged in net-next.git though.

/Thomas