mailing list of musl libc
 help / color / mirror / code / Atom feed
From: CM Graff <cm0graff@gmail.com>
To: musl@lists.openwall.com
Subject: printf family handling of INT_MAX +1 tested on aarch64
Date: Wed, 7 Nov 2018 13:33:13 -0600	[thread overview]
Message-ID: <CAOG6P-M8Uxt==ZQcK7VEEWcjmCQBBOefQTDgB6cZ_RCJkti58w@mail.gmail.com> (raw)

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 <stdio.h>
#include <limits.h>
#include <errno.h>
#include <string.h>
#include <stdlib.h>
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


             reply	other threads:[~2018-11-07 19:33 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-07 19:33 CM Graff [this message]
2018-11-07 20:31 ` Rich Felker
2018-11-07 20:54   ` CM Graff
2018-11-08  2:04     ` Rich Felker
2018-11-08  2:47       ` CM Graff

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAOG6P-M8Uxt==ZQcK7VEEWcjmCQBBOefQTDgB6cZ_RCJkti58w@mail.gmail.com' \
    --to=cm0graff@gmail.com \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).