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=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 12804 invoked from network); 6 Aug 2021 19:40:11 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 6 Aug 2021 19:40:11 -0000 Received: (qmail 23606 invoked by uid 550); 6 Aug 2021 19:40:10 -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 23588 invoked from network); 6 Aug 2021 19:40:09 -0000 X-Virus-Scanned: Debian amavisd-new at disroot.org Mime-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=disroot.org; s=mail; t=1628278797; bh=UltluY+dF/XDyhWwJC8iBbzZbF8Nb4Y+bshBt5zpbhE=; h=To:Subject:From:Date:In-Reply-To; b=ScYa3RLFXxgjK4i3bE6mEf+ibbJ60asMcxF2EJOq5hIeepSEkdssXNVJsibHokinY ldT8ai4YeKCY90DJHoEpi66FhXQmfOw7bXH3++7k7TqE/W5/ReKnXgQNOSYn0RIHxK Hq6Rgq33Md8iT4bNDyjm9dAxIN1htWEYl0O6BDJQJt/G1X/Me0LPXnS5ZRbRnvtf7H Bz624uz+8o9eEmYYKR/rXaGfub8peHw+sSHUe6McTwRoVXV7YTLZMbO4TGrhRQu8uC cTIcXeIwFpAQTLApvm22a0eQBFp7mT+hNZ19vRmwyz0TxTJFSYDmQfZLJ1j4LMybDO vSLoaVM9MhshA== Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 To: , "Rich Felker" From: =?utf-8?q?=C3=89rico_Nogueira?= Date: Fri, 06 Aug 2021 16:35:02 -0300 Message-Id: In-Reply-To: <5e5c78f4-f093-278e-f93a-2a9fd8c24fe6@jensenkarlsson.se> Subject: Re: [musl] Potential bug in printf_core On Fri Aug 6, 2021 at 4:29 PM -03, Pontus Jensen Karlsson wrote: > On 8/6/21 4:20 PM, Rich Felker wrote: > > On Fri, Aug 06, 2021 at 03:14:22PM +0200, Pontus Jensen Karlsson wrote: > >> Hi, > >> > >> I've been trying to build audit-userspace tools for an ARMv7 SBC > >> using musl 1.2.2 as libc. > >> The tool auditd continously segfaults and I've traced it to a printf > >> statement that > >> I have isolated the issue to this piece of code (simplified for > >> debugging purposes): > >> > >> #include > >> #include > >> > >> int main(int argc, char **argv) > >> { > >> =C2=A0=C2=A0=C2=A0 struct timeval tv =3D { > >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 .tv_sec =3D 1000, > >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 .tv_usec =3D 4177777 > >> =C2=A0=C2=A0=C2=A0 }; > >> =C2=A0=C2=A0=C2=A0 char *str =3D "Hello World"; > >> =C2=A0=C2=A0=C2=A0 unsigned num =3D 8062; > >> > >> =C2=A0=C2=A0=C2=A0 printf("%lu %03u %u %s", tv.tv_sec, (unsigned)(tv.= tv_usec), num, str); > >> } > >> > >> This code segfaults at memchr (s =3D 0x3fbf71 >> memory at address 0x3fbf71>) > >> but three frames up we're at src/stdio/vfprintf.c:593. > >> > >> Here it attempts to read the string length from the arg.p address, > >> the problem is that arg.p points > >> to the int-value of (unsigned)(tv.tv_usec) and not the memory > >> address of str. > >> > >> So, I'm confused as to why this happens? Is it something weird with > >> the state-machine in printf_core, > >> or am I misunderstanding something which needs to be patched into > >> audit-userspace? > > You're missing that %lu is not a valid format specifier for time_t. > > You need to either do %jd and (intmax_t)tv.tv_sec or %lld and (long > > long)tv.tv_sec. > > You are absolutely correct. After changing to %llu it worked flawlessly, > well I had > to do it for both tv_sec and tv_usec but after that it works. I also > read the note on > the frontpage of musl.libc.org which explained the reason why this had > to be done. > > My question now is, have most C libraries moved to long long unsigned > for tv_sec, > i.e. is this portable? There is only one portable way of dealing with this, and that is casting the value. You shouldn't worry about the underlying type, only that the type you're casting to can fit it. This way your program can work with *all* C libraries, be they new or old (and will even keep working if someone makes time_t an __int128_t, though you might be losing data in that case, but a compiler would warn about the narrowing conversion). As for the rest of your question, glibc 2.34 just released with support for time64 on 32-bit targets, but it isn't the default yet (requires some #defines). Hopefully 2.35 or 2.36 will make it the default. The BSDs have fixed time64 concerns for a long time now. > > ~ PJK > > > > > So yes, this seems to be a bug in audit-userspace. > > > > Rich