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.3 required=5.0 tests=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 12286 invoked from network); 6 Aug 2021 19:36:37 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 6 Aug 2021 19:36:37 -0000 Received: (qmail 21504 invoked by uid 550); 6 Aug 2021 19:36:35 -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 20462 invoked from network); 6 Aug 2021 19:36:35 -0000 Date: Fri, 6 Aug 2021 15:36:23 -0400 From: Rich Felker To: Pontus Jensen Karlsson Cc: musl@lists.openwall.com Message-ID: <20210806193622.GW13220@brightrain.aerifal.cx> References: <23e62796-4efb-3495-d7c8-1e3d85f4ea82@jensenkarlsson.se> <20210806142038.GU13220@brightrain.aerifal.cx> <5e5c78f4-f093-278e-f93a-2a9fd8c24fe6@jensenkarlsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5e5c78f4-f093-278e-f93a-2a9fd8c24fe6@jensenkarlsson.se> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] Potential bug in printf_core On Fri, Aug 06, 2021 at 09:29:38PM +0200, 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) > >>{ > >>     struct timeval tv = { > >>         .tv_sec = 1000, > >>         .tv_usec = 4177777 > >>     }; > >>     char *str = "Hello World"; > >>     unsigned num = 8062; > >> > >>     printf("%lu %03u %u %s", tv.tv_sec, (unsigned)(tv.tv_usec), num, str); > >>} > >> > >>This code segfaults at memchr (s = 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. I forgot to mention tv_usec because timespec (the modern replacement for timeval) has long tv_nsec rather than an abstract 'nanoseconds' type but timeval has the old suseconds_t. > My question now is, have most C libraries moved to long long > unsigned for tv_sec, > i.e. is this portable? No, that's why you have to cast. The types time_t and suseconds_t are not guaranteed to match any particular standard type that has a printf specifier, so you just have to convert them to a known larger/large-enough type to print them. Rich