From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_LOW,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 22880 invoked from network); 2 Jun 2023 15:23:43 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 2 Jun 2023 15:23:43 -0000 Received: (qmail 11620 invoked by uid 550); 2 Jun 2023 15:23:40 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 11583 invoked from network); 2 Jun 2023 15:23:39 -0000 Date: Fri, 2 Jun 2023 11:23:27 -0400 From: Rich Felker To: Markus Wichmann Cc: musl@lists.openwall.com Message-ID: <20230602152327.GT4163@brightrain.aerifal.cx> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] __convert_scm_timestamps() probably breaks with struct timeval On Fri, Jun 02, 2023 at 04:49:37PM +0200, Markus Wichmann wrote: > 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. I'm confused what problem you're seeing. There is no conversion in-place. The function finds a timeval or timespec in the old cmsg array, extracts the value to a local variable that's a pair of long long, and finally *appends* that as a new cmsg to the cmsg array. Rich