From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/13400 Path: news.gmane.org!.POSTED!not-for-mail From: CM Graff Newsgroups: gmane.linux.lib.musl.general Subject: printf family handling of INT_MAX +1 tested on aarch64 Date: Wed, 7 Nov 2018 13:33:13 -0600 Message-ID: Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Trace: blaine.gmane.org 1541619083 26570 195.159.176.226 (7 Nov 2018 19:31:23 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 7 Nov 2018 19:31:23 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-13416-gllmg-musl=m.gmane.org@lists.openwall.com Wed Nov 07 20:31:18 2018 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1gKTXq-0006oq-5S for gllmg-musl@m.gmane.org; Wed, 07 Nov 2018 20:31:18 +0100 Original-Received: (qmail 11338 invoked by uid 550); 7 Nov 2018 19:33:26 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 11276 invoked from network); 7 Nov 2018 19:33:26 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=38LnY+eBNdCpnm38RhQFwQYQetXbUTtvi1Mu4q1ArHs=; b=APkzgoNCyFJQm/U2vt1GhOOO/rcj+qiuH9Z1aN/dsEmYlHOowJqB8blIszt5Gjmlni rtJsHu9YieilBUISyVXJSk4Am3yrmIk7PED6ZI/Bd0fSjJiAURc5XvbdsM5Eb/mAe4tn r1jVBVpL/ptJrVwxFGlMPdzB2+eEgu3kYGo0LVQRGxr+JR98bvNCC3WixqhnWKBdCWXq gsr1pDCAkwFN8SvgaFsvsSS0o7bAzTKW6pcdfy16lxQnUh0p5u5anHwJr4psP+VYRgHE vXrW1s0MkIJGszQOwLw5wHjLIk+0iRifUipkCnUCMyqsfxP4svhE9GnEInBBj2zREkBk SArQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=38LnY+eBNdCpnm38RhQFwQYQetXbUTtvi1Mu4q1ArHs=; b=G2yCR6vQT+Mli2osK2Ebm9VCrfX2J64xpKIOZAf9KsStSB2nI6BOaF2cU+pk0g35KT eCeCAODaimHEbXv8yC75K0sw7cQ/52r8E5ynrTJV7oC0/2aiN4mttGJRaeJlgsOPh+4S vuzQiv8pwNHQ06UuNELH2XnZPowcuwziwDq0ikAMdEjMo/Bmg5dREacMyyvr8rl99y0J w3aRUpmTDr+MT1CXa+v90P/5CstNMhQIOTkup8/s9+hosJugJlFSNjaawb4XocS/bcoX XaaGwVHwYWTNgx11E8DrTmvXsOV1bnXo2VfAm7YMcrkW38ABKiKIMUU/RkmNsaZeIF84 TD+g== X-Gm-Message-State: AGRZ1gIZ9xiby/FaWnJy9XaUG7glHCASeKtgF6SROaQP8F62qfNdUg+T ghFocSNkz2pqMErCgfApWRcOVaDx80Wrh/e2Pf8NVqfs X-Google-Smtp-Source: AJdET5fwbPLGRK+9qrFZ21hAh4fqPICy5mDU6y4UjkyjpmFjZEUWW1Bk3epgoVSSsdXzm2hi0DMYe1wa5UYxxt1qzNM= X-Received: by 2002:a5d:4609:: with SMTP id t9-v6mr1547570wrq.198.1541619194185; Wed, 07 Nov 2018 11:33:14 -0800 (PST) Xref: news.gmane.org gmane.linux.lib.musl.general:13400 Archived-At: Hello everyone, The C standard states that: "The number of characters or wide characters transmitted by a formatted output function (or written to an array, or that would have been written to an array) is greater than INT_MAX" is undefined behavior. POSIX states that: "In addition, all forms of fprintf() shall fail if: [...] [EOVERFLOW] [CX] [Option Start] The value to be returned is greater than {INT_MAX}. [Option End] " Though arguments of over INT_MAX are undefined behavior it seems like some provisions have been made in musl to handle it, and the method for handling such appear similar in effect to that of glibc and freebsd's libc. INT_MAX + 2 appears to represent this case, however INT_MAX + 1 produces a segfault on my aarch64 test box running debian version 9.5. I do not have a suggested fix other than to either carefully inspect the EOVERFLOW semantics or to mitigate the need for more complex mathematics by using a size_t as the primary counter for the stdio family instead of an int. This segfault was discovered when testing my own small libc (https://github.com/hlibc/hlibc) against the various robust production grade libc to understand more about how to properly handle EOVERFLOW and in general the cases of INT_MAX related undefined behavior for the formatted stdio functions as per specified in the C standard and POSIX. I am not sure that handling this is an important case for musl, however I thought it best to report the scenario as best I could describe it. Here is a script and a small C program to verify this segfault on aarch64, I apologize for not testing on other architectures but my time is limited lately as I'm working toward my degree in mathematics. #!/bin/sh git clone git://git.musl-libc.org/musl cd musl ./configure --prefix=$(pwd)/usr make -j4 > log 2>&1 make install >> log 2>&1 ./usr/bin/musl-gcc -static ../printf_overflow.c ./a.out > log2 #include #include #include #include #include int main(void) { size_t i = INT_MAX; ++i; char *s = malloc(i); if (!(s)) { fprintf(stderr, "unable to allocate enough memory\n"); return 1; } memset(s, 'A', i - 1); s[i] = 0; /* make sure printf is not changed to puts() by the compiler */ int len = printf("%s", s, 1); if (errno == EOVERFLOW) fprintf(stderr, "printf set EOVERFLOW\n"); else fprintf(stderr, "printf did not set EOVERFLOW\n"); fprintf(stderr, "printf returned %d\n", len); return 0; } Thank you for your time, Graff