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] [thread-next>] [day] [month] [year] [list]
Date: Tue, 2 Jan 2024 20:06:09 +0100
From: Thomas Lange <thomas@...elatus.se>
To: Willem de Bruijn <willemdebruijn.kernel@...il.com>,
 netdev@...r.kernel.org, jthinz@...lbox.tu-berlin.de, arnd@...db.de,
 deepa.kernel@...il.com
Subject: Re: net/core/sock.c lacks some SO_TIMESTAMPING_NEW support


On 2024-01-02 16:26, Willem de Bruijn wrote:
> Thomas Lange wrote:
>> 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
> 
> The fix to getsockopt is now merged:
> 
> https://lore.kernel.org/netdev/20231221231901.67003-1-jthinz@mailbox.tu-berlin.de/T/
> 
> Do you want to send the above fix to __sock_cmsg_send? 

Sure, I can do that. Do you want it sent to [net]?

/Thomas

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ