[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZHoBgc69aLVKVscf@voyager>
Date: Fri, 2 Jun 2023 16:49:37 +0200
From: Markus Wichmann <nullplan@....net>
To: musl@...ts.openwall.com
Subject: __convert_scm_timestamps() probably breaks with struct timeval
Hi all,
I couldn't think of a better subject. For unrelated reasons, today I
stumbled upon the abovenamed function. It looks through all control
messages in a msghdr, looking for SCM_TIMESTAMP_OLD and
SCM_TIMESTAMPNS_OLD, and converting an array two long into an array of
two long long.
This will work with struct timespec (or SCM_TIMESTAMPNS_OLD) on all
architectures, because struct timespec has been defined specifically for
this to work (due to the kernel accessing it the same way). But it will
break with struct timeval (or SCM_TIMESTAMP_OLD).
First of all, on some 32-bit archs (and this code is only used on 32-bit
archs) we have alignof(int64_t) == 4, and therefore sizeof (struct
timeval) == 12. Therefore CMSG_LEN(sizeof (long long[2])) !=
CMSG_LEN(struct timeval), and therefore, applications won't read the
newly converted cmsg. All the work for nothing.
Next, even if alignof(int64_t) == 8, struct timeval does not have the
same padding as struct timespec, and so on big endian architectures, the
code ends up writing the microseconds into the padding and clearing the
tv_usec field.
This can all be solved easily, if you just try to be a touch less
clever. I am attaching a patch that makes the intent more obvious. It's
not as flashy as the previous code. It doesn't have a switch with a goto
in it. I hope it finds your favor.
Ciao,
Markus
View attachment "0001-Fix-time64-conversion-of-SCM_TIMESTAMP.patch" of type "text/x-diff" (2925 bytes)
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
