Bug 13138 - scanf crashes on very long numbers
Summary: scanf crashes on very long numbers
Alias: None
Product: glibc
Classification: Unclassified
Component: libc (show other bugs)
Version: unspecified
: P2 critical
Target Milestone: ---
Assignee: Ulrich Drepper
Depends on:
Reported: 2011-08-28 11:30 UTC by Lauri Nurmi
Modified: 2015-03-05 10:09 UTC (History)
5 users (show)

See Also:
Last reconfirmed:
fweimer: security+


Note You need to log in before you can comment on or make changes to this bug.
Description Lauri Nurmi 2011-08-28 11:30:32 UTC
As pointed out by someone at <http://marc.info/?l=gimp-developer&m=129567990905823&w=2>, the scanf implementation of glibc will crash when given input containing a lot of digits.

This is the sample code copied from the post mentioned above:

#include <stdio.h>
int main()
    int a;
    scanf("%i", &a);
    return 0;

Expected output none; actual output:

$ perl -e 'print "5"x21000000' | ./a.out
Segmentation fault

Tested and reproduced on:
RHEL 5.7 (x86_64)
Debian Squeeze (armv5tel)
Comment 1 Thomas Jarosch 2011-08-29 11:28:16 UTC
Same thing on Fedora 14 (x86_64).
Comment 2 Lauri Nurmi 2011-09-02 15:07:16 UTC
Good news everyone:
ISO C99 ยง7.19.6.2 item 10 says:
"[...] the result of the conversion is placed in the object pointed to by [...]. If this object does not have an appropriate type, or if the result of the conversion cannot be represented in the object, the behavior is undefined."

So the standard permits the crash; problem solved.

I'll leave this bug open though, so that alternatives to segfaulting can be considered.
Comment 3 Rich Felker 2011-09-03 05:08:56 UTC
POSIX uses the more-clear language "or if the result of the conversion cannot be represented in the space provided" rather than "... in the object". In either case, I believe this is referring to string conversions that overflow the destination buffer, not numeric conversions. I can't find any language regarding what happens when a numeric value is outside the range of the type, but the expected form is specified in terms of strtol, etc., so it would not be unreasonable to expect scanf to behave the same as these functions.

By the way, can the bug be reproduced with a huge string of zeros? If so, the numeric overflow issue is irrelevant and the behavior is definitely well-defined by the standard.
Comment 4 Lauri Nurmi 2011-09-03 06:33:54 UTC
(In reply to comment #3)
> By the way, can the bug be reproduced with a huge string of zeros?

Yes it can.
Comment 5 Ulrich Drepper 2011-09-10 01:29:30 UTC
I checked in a patch.
Comment 6 Florian Weimer 2014-06-13 14:34:25 UTC
Fix: https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=3f8cc204fdd0

The fix is part of glibc 2.15.  The issue was present since the dawn of times.
Comment 7 Andreas Schwab 2015-03-04 10:35:33 UTC
Follow-up fix: https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=20b38e0
Comment 8 Florian Weimer 2015-03-04 18:52:02 UTC
(In reply to Andreas Schwab from comment #7)
> Follow-up fix: https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=20b38e0

I think this is just a performance fix because the buffer is populated by one character at a time, so __libc_use_alloca is always true on the first buffer extension, and then we are in the use_malloc case.
Comment 9 Andreas Schwab 2015-03-04 21:40:57 UTC
It's still a logic error.
Comment 10 Florian Weimer 2015-03-05 06:26:33 UTC
(In reply to Andreas Schwab from comment #9)
> It's still a logic error.

What do you mean?  Clearly, the code does not do what is intended, but as far as I can tell, there is no observable impact whatsoever (not even performance).
Comment 11 Andreas Schwab 2015-03-05 10:09:58 UTC
A logic error is an error in the logic.