date:20171016

bug#28859: Segmentation fault with NULL pointer dereference in 'stty'

2017-10-16 Thread Jim Meyering

On Mon, Oct 16, 2017 at 2:30 AM, Pádraig Brady  wrote:
> On 15/10/17 18:07, Jaeseung Choi wrote:
>> Dear GNU team,
>>
>> While testing coreutils for a research purpose, we found the following
>> crash in 'stty'. Running stty with the command-line "stty eol -F AA"
>> raises a crash as below. We did not change any terminal setting, and
>> believe the bug is irrelevant from any specific terminal
>> configuration.
>>
>> jason@ubuntu:~$ tar -xf coreutils-8.28.tar.xz
>> jason@ubuntu:~$ cd coreutils-8.28/
>> jason@ubuntu:~/coreutils-8.28$ mkdir obj
>> jason@ubuntu:~/coreutils-8.28$ cd obj
>> jason@ubuntu:~/coreutils-8.28/obj$ ../configure --disable-nls && make
>> ...
>> jason@ubuntu:~/coreutils-8.28/obj$ gdb ./src/stty -q
>> Reading symbols from ./src/stty...done.
>> (gdb) run eol -F AA
>> Starting program: /home/jason/coreutils-8.28/obj/src/stty eol -F AA
>>
>> Program received signal SIGSEGV, Segmentation fault.
>> set_control_char (info=0x40a6f8 , info=0x40a6f8
>> , mode=0x6103c0 , arg=0x0) at
>> ../src/stty.c:1695
>> 1695  else if (arg[0] == '\0' || arg[1] == '\0')
>> (gdb) x/i $rip
>> => 0x40387a :   movzbl (%rbx),%r14d
>> (gdb) info reg rbx
>> rbx0x0  0
>> (gdb)
>>
>> We could reproduce the bug in coreutils from version 8.27 to 8.28.
>> Also, the bug was reproducible in both Ubuntu 16.04 and Debian 9.1.
>> But the stty program pre-built in Debian 9.1 did not crash because
>> currently 8.26 version is installed in Debian.
>
> This is actually an old bug which you can reproduce with -F /dev/tty.
> The attached should fix it up.

Thank you!
If it's not too hard to determine, would you please mention in the log
the commit that introduced the bug?

bug#28847: Maybe a bug in "sort (GNU coreutils) 8.4" report

2017-10-16 Thread Eric Blake

tag 28847 notabug
thanks

On 10/15/2017 02:58 AM, kakaxixi777 wrote:
>Dear coreutils :
>I am a Research and Development Engineer in IT. I met a situation when
>I use “sort” command in Linux shell which could be a bug for the "sort"
>command. So I hope you read this email, thank you !
>The whole command I used was ：
>sort test.txt
>And the result was :
>20171012|3|2059517|-|8|-|20-24|2|-|2.0|2.0
>20171012|3|2059517|-|82|-|25-29|2|-|13.0|12.0
>20171012|3|2059517|-|8|-|-2|-2|-|71.0|64.0
>20171012|3|2059517|-|82|-|30-34|0|-|2.0|1.0
>The content in test.txt was:
>20171012|3|2059517|-|8|-|20-24|2|-|2.0|2.0
>20171012|3|2059517|-|82|-|25-29|2|-|13.0|12.0
>20171012|3|2059517|-|8|-|-2|-2|-|71.0|64.0
>20171012|3|2059517|-|82|-|30-34|0|-|2.0|1.0

Your situation is a FAQ:
https://www.gnu.org/software/coreutils/faq/coreutils-faq.html#Sort-does-not-sort-in-normal-order_0021

Most likely, you are sorting in a locale that does not treat punctuation
with the same weight as digits, such as en_US.UTF8.  If you'll notice,
the substring '8202' sorts before '8225' which in turn is before '8227'
and finally '8230', once you've ignored the punctuation in '8|-|20-2',
'82|-|25', and so forth.

>Which means the “sort” command didn't work, because I think the correct
>result should be :
>20171012|3|2059517|-|8|-|20-24|2|-|2.0|2.0
>20171012|3|2059517|-|8|-|20-24|2|-|2.0|2.0
>20171012|3|2059517|-|82|-|25-29|2|-|13.0|12.0
>20171012|3|2059517|-|82|-|25-29|2|-|13.0|12.0

Well, this isn't the right result either, as it is duplicating two lines
and missing two others (did you copy and past incorrectly?).

>The version of "sort" command I use is : sort --version
>"sort (GNU coreutils) 8.4

This version is rather old; we are now at 8.28.  But even as recently as
version 8.6, you can use sort's --debug feature to see where your
expectations are going wrong (as 99% of reports about sort misbehavior
turn out to instead be problems of misuse of either command line options
or current locale).  Observe the difference:

$ printf
'20171012|3|2059517|-|8|-|20-24|2|-|2.0|2.0\n20171012|3|2059517|-|82|-|25-29|2|-|13.0|12.0\n20171012|3|2059517|-|8|-|-2|-2|-|71.0|64.0\n'
| LC_ALL=en_US.UTF8 sort  --debug
sort: using ‘en_US.UTF8’ sorting rules
20171012|3|2059517|-|8|-|20-24|2|-|2.0|2.0
__
20171012|3|2059517|-|82|-|25-29|2|-|13.0|12.0
_
20171012|3|2059517|-|8|-|-2|-2|-|71.0|64.0
__

$ printf
'20171012|3|2059517|-|8|-|20-24|2|-|2.0|2.0\n20171012|3|2059517|-|82|-|25-29|2|-|13.0|12.0\n20171012|3|2059517|-|8|-|-2|-2|-|71.0|64.0\n'
| LC_ALL=C sort  --debug
sort: using simple byte comparison
20171012|3|2059517|-|82|-|25-29|2|-|13.0|12.0
_
20171012|3|2059517|-|8|-|-2|-2|-|71.0|64.0
__
20171012|3|2059517|-|8|-|20-24|2|-|2.0|2.0
__

And if you want the lines containing '|8|' to sort before the lines
containing '|82|', then you can't use plain sort (which is over the
whole line), but instead need to use various -k, -n, and -t options to
tell sort where the keys are separated and which keys to sort on, and
the fact that the keys should be treated as numbers rather than as
character strings (since when sorting an entire line in ASCII, digits
sort before |).

>I am not sure if it is a bug in "sort" command in Linux Shell or maybe
>it's only my problems in using it.

I think I've demonstrated where the problem was, so I'm closing this as
not a bug.  Feel free to reply with further questions on the topic, though.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

signature.asc
Description: OpenPGP digital signature

bug#28859: Segmentation fault with NULL pointer dereference in 'stty'

2017-10-16 Thread Pádraig Brady

On 15/10/17 18:07, Jaeseung Choi wrote:
> Dear GNU team,
> 
> While testing coreutils for a research purpose, we found the following
> crash in 'stty'. Running stty with the command-line "stty eol -F AA"
> raises a crash as below. We did not change any terminal setting, and
> believe the bug is irrelevant from any specific terminal
> configuration.
> 
> jason@ubuntu:~$ tar -xf coreutils-8.28.tar.xz
> jason@ubuntu:~$ cd coreutils-8.28/
> jason@ubuntu:~/coreutils-8.28$ mkdir obj
> jason@ubuntu:~/coreutils-8.28$ cd obj
> jason@ubuntu:~/coreutils-8.28/obj$ ../configure --disable-nls && make
> ...
> jason@ubuntu:~/coreutils-8.28/obj$ gdb ./src/stty -q
> Reading symbols from ./src/stty...done.
> (gdb) run eol -F AA
> Starting program: /home/jason/coreutils-8.28/obj/src/stty eol -F AA
> 
> Program received signal SIGSEGV, Segmentation fault.
> set_control_char (info=0x40a6f8 , info=0x40a6f8
> , mode=0x6103c0 , arg=0x0) at
> ../src/stty.c:1695
> 1695  else if (arg[0] == '\0' || arg[1] == '\0')
> (gdb) x/i $rip
> => 0x40387a :   movzbl (%rbx),%r14d
> (gdb) info reg rbx
> rbx0x0  0
> (gdb)
> 
> We could reproduce the bug in coreutils from version 8.27 to 8.28.
> Also, the bug was reproducible in both Ubuntu 16.04 and Debian 9.1.
> But the stty program pre-built in Debian 9.1 did not crash because
> currently 8.26 version is installed in Debian.

This is actually an old bug which you can reproduce with -F /dev/tty.
The attached should fix it up.

thanks!
Pádraig

>From 5e74a57e1b1491ab3a66dc6b6cf6b6d3ae36a138 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?P=C3=A1draig=20Brady?= 
Date: Mon, 16 Oct 2017 02:17:34 -0700
Subject: [PATCH] stty: fix processing of options when -F is specified

* src/stty.c (main): Pass argi+1 so that already processed options
are not considered in the argument count.  This is significant
when -F is specified.
* NEWS: Mention the fix.
* tests/misc/stty-invalid.sh: Add a test case.
Fixes https://bugs.gnu.org/28859
---
 NEWS   | 3 +++
 src/stty.c | 4 ++--
 tests/misc/stty-invalid.sh | 6 ++
 3 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/NEWS b/NEWS
index 2878b70..13a3ee0 100644
--- a/NEWS
+++ b/NEWS
@@ -11,6 +11,9 @@ GNU coreutils NEWS-*- outline -*-
   to attempt to hide the original length of the file name.
   [bug introduced in coreutils-8.28]
 
+  stty no longer crashes when processing settings with -F also specified.
+  [bug instroduced in coreutils-5.3.0]
+
 ** Build-related
 
   Default man pages are now distributed which are used if perl is
diff --git a/src/stty.c b/src/stty.c
index 48aac59..8957595 100644
--- a/src/stty.c
+++ b/src/stty.c
@@ -1383,7 +1383,7 @@ main (int argc, char **argv)
   if (!noargs && !verbose_output && !recoverable_output)
 {
   static struct termios check_mode;
-  apply_settings (/* checking= */ true, device_name, argv, argc,
+  apply_settings (/* checking= */ true, device_name, argv, argi + 1,
   &check_mode, &speed_was_set, &require_set_attr);
 }
 
@@ -1411,7 +1411,7 @@ main (int argc, char **argv)
 
   speed_was_set = false;
   require_set_attr = false;
-  apply_settings (/* checking= */ false, device_name, argv, argc,
+  apply_settings (/* checking= */ false, device_name, argv, argi + 1,
   &mode, &speed_was_set, &require_set_attr);
 
   if (require_set_attr)
diff --git a/tests/misc/stty-invalid.sh b/tests/misc/stty-invalid.sh
index 06186e9..7402c93 100755
--- a/tests/misc/stty-invalid.sh
+++ b/tests/misc/stty-invalid.sh
@@ -41,6 +41,12 @@ returns_ 1 stty $(echo $saved_state |sed 's/^[^:]*:/'$hex_2_64:/) \
 returns_ 1 stty $(echo $saved_state |sed 's/:[0-9a-f]*$/:'$hex_2_64/) \
   2>/dev/null || fail=1
 
+# From coreutils 5.3.0 to 8.28, the following would crash
+# due to incorrect argument handling.
+if tty -s

bug#28860: Segmentation fault with out-of-bound read in 'b2sum'

2017-10-16 Thread Pádraig Brady

On 15/10/17 18:04, Jaeseung Choi wrote:
> Dear GNU team,
> 
> While testing coreutils for a research purpose, we found the following
> segfault in 'b2sum'. Running b2sum with --check option, and simply
> providing a string "BLAKE2" with no trailing character raises the
> crash as below.

Wow thanks! Were you fuzzing the inputs?
Can you give more details on your testing?

The attached should fix this case.

thanks!
Pádraig

>From 94719b21bb80e51a90d51917583a57d1180918c8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?P=C3=A1draig=20Brady?= 
Date: Mon, 16 Oct 2017 01:04:37 -0700
Subject: [PATCH] b2sum: fix crash with --check and truncated input

* src/md5sum.c (split_3): Ensure we don't walk off
the end of the string.
* tests/misc/b2sum.sh: Add test cases.
Fixes https://bugs.gnu.org/28860
---
 src/md5sum.c| 3 ++-
 tests/misc/b2sum.sh | 5 +
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/src/md5sum.c b/src/md5sum.c
index a7e2a9e..c800231 100644
--- a/src/md5sum.c
+++ b/src/md5sum.c
@@ -430,7 +430,8 @@ split_3 (char *s, size_t s_len,
 #if HASH_ALGO_BLAKE2
   /* Terminate and match algorithm name.  */
   char const *algo_name = &s[i - algo_name_len];
-  while (! ISWHITE (s[i]) && s[i] != '-' && s[i] != '(')
+  /* Skip algorithm variants.  */
+  while (s[i] && ! ISWHITE (s[i]) && s[i] != '-' && s[i] != '(')
 ++i;
   bool length_specified = s[i] == '-';
   bool openssl_format = s[i] == '('; /* and no length_specified */
diff --git a/tests/misc/b2sum.sh b/tests/misc/b2sum.sh
index d16427c..28fd95b 100755
--- a/tests/misc/b2sum.sh
+++ b/tests/misc/b2sum.sh
@@ -46,4 +46,9 @@ b2sum -l 128 check.vals > out || fail=1
 printf '%s\n' '796485dd32fe9b754ea5fd6c721271d9  check.vals' > exp
 compare exp out || fail=1
 
+# This would segfault from coreutils-8.26 to coreutils-8.28
+printf '%s\n' 'BLAKE2' 'BLAKE2b' 'BLAKE2-' 'BLAKE2(' 'BLAKE2 (' > crash.check \
+  || framework_failure_
+returns_ 1 b2sum -c crash.check || fail=1
+
 Exit $fail
-- 
2.9.3

bug#28860: Segmentation fault with out-of-bound read in 'b2sum'

2017-10-16 Thread Jaeseung Choi

Dear GNU team,

While testing coreutils for a research purpose, we found the following
segfault in 'b2sum'. Running b2sum with --check option, and simply
providing a string "BLAKE2" with no trailing character raises the
crash as below.

jason@ubuntu:~$ tar -xf coreutils-8.28.tar.xz
jason@ubuntu:~$ cd coreutils-8.28/
jason@ubuntu:~/coreutils-8.28$ mkdir obj
jason@ubuntu:~/coreutils-8.28$ cd obj
jason@ubuntu:~/coreutils-8.28/obj$ ../configure --disable-nls && make
...
jason@ubuntu:~/coreutils-8.28/obj$ gdb ./src/b2sum -q
Reading symbols from ./src/b2sum...done.
(gdb) run --check <<< BLAKE2
Starting program: /home/jason/coreutils-8.28/obj/src/b2sum --check <<< BLAKE2

Program received signal SIGSEGV, Segmentation fault.
split_3 (file_name=, binary=,
hex_digest=, s_len=, s=0x60dfe0
"BLAKE2") at ../src/md5sum.c:433
433   while (! ISWHITE (s[i]) && s[i] != '-' && s[i] != '(')
(gdb) x/i $rip
=> 0x401d0e :movzbl (%r12,%rbx,1),%ebp
(gdb) info reg r12 rbx
r120x60dfe0 6348768
rbx0x20020  131104
(gdb)

We could reproduce the bug in coreutils from version 8.26 to 8.28.
Also, the bug was reproducible in both Ubuntu 16.04 and Debian 9.1,
but the b2sum program pre-built in Debian 9.1 did not crash with this
input. We assume it is due to a difference in the configuration before
build.

Please let us know if you have a problem in reproducing the bug.

Thank you.

Sincerely,
Jaeseung

bug#28846: 回复： bug#28846: Maybe a bug in "sort (GNU coreutils) 8.4" report

2017-10-16 Thread kakaxixi777

   Sorry maybe I didn't speak clearly, I want to sort on the whole line by
   each character from left to right, not only the 5 fields。
   And why I use the same command "sort test.txt" and same input
   "test.txt" on the 2016 Mac pro or on the windows10 , the result both
   are :
   20171012|3|2059517|-|8|-|20-24|2|-|2.0|2.0
   20171012|3|2059517|-|8|-|20-24|2|-|2.0|2.0
   20171012|3|2059517|-|82|-|25-29|2|-|13.0|12.0
   20171012|3|2059517|-|82|-|25-29|2|-|13.0|12.0
   which are different from the Linux shell, and that is the correct
   result I want. Is that normal ?
   The "sort" version on Mac pro is :
   "sort (GNU coreutils) 5.93
   Copyright (C) 2005 Free Software Foundation, Inc.
   This is free software.  You may redistribute copies of it under the
   terms of
   the GNU General Public License .
   There is NO WARRANTY, to the extent permitted by law.
   Written by Mike Haertel and Paul Eggert."
   I don't know why so I am look forward to receive your reply as soon as
   possible.
   Thank you very much!
Sincerely yours,
Frank

   在2017年10月16日 07:36，[1]Pádraig Brady 写道：

 forcemerge 28846 28847
 tag 28846 notabug
 close 28846
 stop
 On 15/10/17 01:03, Tree Big wrote:
 > Dear coreutils :
 > I am a Research and Development Engineer in IT. I met a situation
 when I
 > use “sort” command in Linux shell which could be a bug for the "so
 rt"
 > command. So I hope you read this email, thank you !
 >
 > The whole command I used was ：
 > *sort test.txt*
 >
 > *And the result was :*
 > 20171012|3|2059517|-|8|-|20-24|2|-|2.0|2.0
 > 20171012|3|2059517|-|82|-|25-29|2|-|13.0|12.0
 > 20171012|3|2059517|-|8|-|-2|-2|-|71.0|64.0
 > 20171012|3|2059517|-|82|-|30-34|0|-|2.0|1.0
 Since at least field 5 is variable width
 you can't so a simple sort on the whole line.
 I'm not sure exactly what field order you want
 but you'll want something like:
   sort -t'|' -k1,1 -k5,5n
 cheers,
 Pádraig

References

   1. mailto:p...@draigbrady.com

bug#28859: Segmentation fault with NULL pointer dereference in 'stty'

bug#28847: Maybe a bug in "sort (GNU coreutils) 8.4" report

bug#28859: Segmentation fault with NULL pointer dereference in 'stty'

bug#28860: Segmentation fault with out-of-bound read in 'b2sum'

bug#28860: Segmentation fault with out-of-bound read in 'b2sum'

bug#28846: 回复： bug#28846: Maybe a bug in "sort (GNU coreutils) 8.4" report

6 matches

Site Navigation

Mail list logo

Footer information