public inbox for glibc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug stdio/15929] New: scanf doesn't set errno to ERANGE for unsigned short overflows
@ 2013-09-04 11:55 filipe at codinghighway dot com
2013-09-04 12:42 ` [Bug stdio/15929] " schwab@linux-m68k.org
` (4 more replies)
0 siblings, 5 replies; 6+ messages in thread
From: filipe at codinghighway dot com @ 2013-09-04 11:55 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=15929
Bug ID: 15929
Summary: scanf doesn't set errno to ERANGE for unsigned short
overflows
Product: glibc
Version: 2.18
Status: NEW
Severity: normal
Priority: P2
Component: stdio
Assignee: unassigned at sourceware dot org
Reporter: filipe at codinghighway dot com
Created attachment 7186
--> https://sourceware.org/bugzilla/attachment.cgi?id=7186&action=edit
Sample code that is able to reproduce the bug
Overview:
When scanf is called with %hu to parse an unsigned short from input, ERANGE is
not being set for values that do not fit inside an unsigned short.
Steps to reproduce:
Compile the attached program. Run the program and try entering different
values. On a machine with 16-bit shorts, entering a number that a short can't
store, like 70000, will not trigger errno to be set to ERANGE.
Actual results:
errno is not set to ERANGE. The value read wraps around and there's no way for
the caller to know if there has been an overflow. In a system with n-bit
shorts, if number x is read, the actual value stored is x%(2^n) (it wraps
around).
Expected results:
errno should have been set to ERANGE.
Build date & hardware:
Tested with debian's built-in glibc 2.13, and also with the latest version,
2.18, compiled from official source.
filipe@debian:~/glibc-build$ uname -a
Linux debian 3.2.0-4-486 #1 Debian 3.2.46-1 i686 GNU/Linux
Additional information:
I happened to notice that errno is correctly set if the value entered is
greater than INT_MAX. So, apparently, it looks like scanf ignores the fact that
it is given a pointer to unsigned short, treating it as pointer to int instead.
Thus, every value between USHRT_MAX and INT_MAX is assumed to fit into a short.
Here's an example in my system:
$ ./bug
Enter a number: 65535
You entered 65535
Enter a number: 65536
You entered 0
Enter a number: 2000000
You entered 33920
Enter a number: 2000000000000000000000000000000000000000000000000
Value is too large, try again.
Enter a number:
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug stdio/15929] scanf doesn't set errno to ERANGE for unsigned short overflows
2013-09-04 11:55 [Bug stdio/15929] New: scanf doesn't set errno to ERANGE for unsigned short overflows filipe at codinghighway dot com
@ 2013-09-04 12:42 ` schwab@linux-m68k.org
2013-09-04 13:59 ` filipe at codinghighway dot com
` (3 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: schwab@linux-m68k.org @ 2013-09-04 12:42 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=15929
--- Comment #1 from Andreas Schwab <schwab@linux-m68k.org> ---
POSIX does not specify ERANGE for fscanf. The ERANGE error comes from strtoul
which checks against ULONG_MAX (not UINT_MAX). If you want to do range
checking you have to do it yourself.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug stdio/15929] scanf doesn't set errno to ERANGE for unsigned short overflows
2013-09-04 11:55 [Bug stdio/15929] New: scanf doesn't set errno to ERANGE for unsigned short overflows filipe at codinghighway dot com
2013-09-04 12:42 ` [Bug stdio/15929] " schwab@linux-m68k.org
@ 2013-09-04 13:59 ` filipe at codinghighway dot com
2013-09-04 20:32 ` schwab@linux-m68k.org
` (2 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: filipe at codinghighway dot com @ 2013-09-04 13:59 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=15929
--- Comment #2 from Filipe Gonçalves <filipe at codinghighway dot com> ---
(In reply to Andreas Schwab from comment #1)
> POSIX does not specify ERANGE for fscanf. The ERANGE error comes from
> strtoul which checks against ULONG_MAX (not UINT_MAX). If you want to do
> range checking you have to do it yourself.
Well, the manpage contradicts itself, it mentions that ERANGE is used when "The
result of an integer conversion would exceed the size that can be stored in the
corresponding integer type.", but later on it says that the standards to which
it conforms to do not mention ERANGE. What do we have then?
If I call scanf, I can't do range checking, by the time it returns, how am I
supposed to know if there was an overflow?
If ERANGE is not mentioned in the standards and that serves as an excuse on why
scanf doesn't deal with it properly, then it might be better to remove that
from the "ERRORS" section, otherwise, we have an awkward situation here, where
it kind of works, but when it doesn't, it's not a bug because the standard
doesn't mention it.
But ok then, I'll just code my own function to read an unsigned short and
forget that scanf exists.
--
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-19493-listarch-glibc-bugs=sources.redhat.com@sourceware.org Wed Sep 04 17:05:29 2013
Return-Path: <glibc-bugs-return-19493-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 19714 invoked by alias); 4 Sep 2013 17:05:29 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 19677 invoked by uid 48); 4 Sep 2013 17:05:24 -0000
From: "pchang9 at cs dot wisc.edu" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug libc/15931] New: memcpy() has different behavior when statically linked (x86_64)
Date: Wed, 04 Sep 2013 17:05:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: libc
X-Bugzilla-Version: 2.18
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: pchang9 at cs dot wisc.edu
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter cc
Message-ID: <bug-15931-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-09/txt/msg00033.txt.bz2
Content-length: 1950
https://sourceware.org/bugzilla/show_bug.cgi?id\x15931
Bug ID: 15931
Summary: memcpy() has different behavior when statically linked
(x86_64)
Product: glibc
Version: 2.18
Status: NEW
Severity: normal
Priority: P2
Component: libc
Assignee: unassigned at sourceware dot org
Reporter: pchang9 at cs dot wisc.edu
CC: drepper.fsp at gmail dot com
Hi,
In latest git commit a442b23, I notice memcpy() has different behavior
when statically linked on x86_64. Specifically, the test program has three
character arrays "a", "b" and "c". It copies the whole "b" to "a" by memcpy()
and prints the last element of "b" before exiting. Before the memcpy(),
I intentionally set the x86 DF flag by "std" instruction. When dynamically
linked with x86_64 multiarch library, it works correctly.
pcchang@T420 ~/glibc_bug $ cat test.c
#include <stdio.h>
#include <string.h>
void main(void) {
char a[65536];
char b[] = { [0 ... 65535] = 'b'};
char c[] = { [0 ... 65535] = 'c'};
printf("b[65535] before memcpy(): %c\n", b[65535]);
asm volatile ("std");
memcpy(a, b, sizeof(a));
printf("b[65535] after memcpy(): %c\n", b[65535]);
}
pcchang@T420 ~/glibc_bug $ gcc -O0 -ggdb test.c -o test
pcchang@T420 ~/glibc_bug $ ./test
b[65535] before memcpy(): b
b[65535] after memcpy(): b
pcchang@T420 ~/glibc_bug $
However, when statically linked, the content of array "b" changes.
pcchang@T420 ~/glibc_bug $ gcc -O0 -ggdb test.c -o test -static
pcchang@T420 ~/glibc_bug $ ./test
b[65535] before memcpy(): b
b[65535] after memcpy(): c
pcchang@T420 ~/glibc_bug $
The problem seems to be the "movsq" in sysdeps/x86_64/memcpy.S after label
"L(fast)", which implicitly assumes the DF flag is clear.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug stdio/15929] scanf doesn't set errno to ERANGE for unsigned short overflows
2013-09-04 11:55 [Bug stdio/15929] New: scanf doesn't set errno to ERANGE for unsigned short overflows filipe at codinghighway dot com
2013-09-04 12:42 ` [Bug stdio/15929] " schwab@linux-m68k.org
2013-09-04 13:59 ` filipe at codinghighway dot com
@ 2013-09-04 20:32 ` schwab@linux-m68k.org
2013-09-06 6:15 ` carlos at redhat dot com
2014-06-13 12:57 ` fweimer at redhat dot com
4 siblings, 0 replies; 6+ messages in thread
From: schwab@linux-m68k.org @ 2013-09-04 20:32 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=15929
--- Comment #3 from Andreas Schwab <schwab@linux-m68k.org> ---
There are no manpages as part of glibc, you should report this to the provider
of them (probably the man-pages project).
scanf is really only useful for very simple interaction. If you want more
sophisticated behaviour you need to parse the input yourself.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug stdio/15929] scanf doesn't set errno to ERANGE for unsigned short overflows
2013-09-04 11:55 [Bug stdio/15929] New: scanf doesn't set errno to ERANGE for unsigned short overflows filipe at codinghighway dot com
` (2 preceding siblings ...)
2013-09-04 20:32 ` schwab@linux-m68k.org
@ 2013-09-06 6:15 ` carlos at redhat dot com
2014-06-13 12:57 ` fweimer at redhat dot com
4 siblings, 0 replies; 6+ messages in thread
From: carlos at redhat dot com @ 2013-09-06 6:15 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=15929
Carlos O'Donell <carlos at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
CC| |carlos at redhat dot com
Resolution|--- |INVALID
--- Comment #4 from Carlos O'Donell <carlos at redhat dot com> ---
Closing this as invalid since the code and manual are correct. Changes to the
POSIX standard need to go through the Austin Group.
Please note that manual pages, likely the Linux kernel manual pages, are not
the canonical source of documentation for glibc.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug stdio/15929] scanf doesn't set errno to ERANGE for unsigned short overflows
2013-09-04 11:55 [Bug stdio/15929] New: scanf doesn't set errno to ERANGE for unsigned short overflows filipe at codinghighway dot com
` (3 preceding siblings ...)
2013-09-06 6:15 ` carlos at redhat dot com
@ 2014-06-13 12:57 ` fweimer at redhat dot com
4 siblings, 0 replies; 6+ messages in thread
From: fweimer at redhat dot com @ 2014-06-13 12:57 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=15929
Florian Weimer <fweimer at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Flags| |security-
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2014-06-13 12:57 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-09-04 11:55 [Bug stdio/15929] New: scanf doesn't set errno to ERANGE for unsigned short overflows filipe at codinghighway dot com
2013-09-04 12:42 ` [Bug stdio/15929] " schwab@linux-m68k.org
2013-09-04 13:59 ` filipe at codinghighway dot com
2013-09-04 20:32 ` schwab@linux-m68k.org
2013-09-06 6:15 ` carlos at redhat dot com
2014-06-13 12:57 ` fweimer at redhat dot com
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 read-only IMAP folder(s) and NNTP newsgroup(s).