bug#25004: Bug in OD utility

2016-11-23 Thread Jim Meyering 
On Wed, Nov 23, 2016 at 5:16 PM, Marcel Böhme  wrote:
> Hi Pádraig,
>
>> On 24 Nov 2016, at 8:45 AM, Pádraig Brady  wrote:
>>
>> I can't reproduce the issue here BTW with ASAN and running in a tight
>> loop for a few minutes.  So perhaps it has been fixed in glibc already?
>> I have glibc-2.22-10.fc23.x86_64
>> Depending on how widespread the issue is will determine if it's worth
>> adding the check to gnulib.
>
> I can reproduce the crash on Ubuntu 14.04 x86_64 with preinstalled od version 
> 8.21 and the version in trunk.
>
>> What libc are you using?
>
> $ /lib/x86_64-linux-gnu/libc.so.6
> GNU C Library (Ubuntu EGLIBC 2.19-0ubuntu6.9) stable release version 2.19, by 
> Roland McGrath et al.
> Copyright (C) 2014 Free Software Foundation, Inc.
...
> Compiled by GNU CC version 4.8.4.
...

Both gcc-4.8.4 and EGLIBC 2.19 are showing their age.
I too have failed to reproduce this. I used a Fedora 25 system, which
has glibc-2.24.

bug#25004: Bug in OD utility

2016-11-23 Thread Paul Eggert 

Marcel Böhme wrote:

I can reproduce the crash on Ubuntu 14.04 x86_64 with preinstalled od version 
8.21 and the version in trunk.


I can't reproduce it in Ubuntu 16.04.1 x86-64 with preinstalled od. This is 
glibc 2.23-0ubuntu4. I hope the bug, whatever it was, was fixed in glibc so that 
we no longer have to worry about it.

bug#25004: Bug in OD utility

2016-11-23 Thread Pádraig Brady 
On 24/11/16 01:16, Marcel Böhme wrote:
> Hi Pádraig,
> 
>> On 24 Nov 2016, at 8:45 AM, Pádraig Brady  wrote:
>>
>> I can't reproduce the issue here BTW with ASAN and running in a tight
>> loop for a few minutes.  So perhaps it has been fixed in glibc already?
>> I have glibc-2.22-10.fc23.x86_64
>> Depending on how widespread the issue is will determine if it's worth
>> adding the check to gnulib.
> 
> I can reproduce the crash on Ubuntu 14.04 x86_64 with preinstalled od version 
> 8.21 and the version in trunk.
> 
>> What libc are you using?
> 
> $ /lib/x86_64-linux-gnu/libc.so.6
> GNU C Library (Ubuntu EGLIBC 2.19-0ubuntu6.9) stable release version 2.19, by 
> Roland McGrath et al.
> Copyright (C) 2014 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.
> There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
> PARTICULAR PURPOSE.
> Compiled by GNU CC version 4.8.4.
> Compiled on a Linux 3.13.11 system on 2016-05-26.
> Available extensions:
>   crypt add-on version 2.1 by Michael Glad and others
>   GNU Libidn by Simon Josefsson
>   Native POSIX Threads Library by Ulrich Drepper et al
>   BIND-8.2.3-T5B
> libc ABIs: UNIQUE IFUNC
> For bug reporting instructions, please see:
> .

For completeness, where we discussed the this in relation to gnulib last was:
  https://sourceware.org/ml/libc-alpha/2015-02/threads.html#00181
and drilling down to there is the reference to original crash bug:
  https://sourceware.org/bugzilla/show_bug.cgi?id=4586
That was fixed in 2007 so this must be something else.

thanks,
Pádraig

bug#25003: Bug in SPLIT utility

2016-11-23 Thread Jim Meyering 
On Wed, Nov 23, 2016 at 4:21 PM, Pádraig Brady  wrote:
> On 23/11/16 22:16, Pádraig Brady wrote:
>> On 23/11/16 17:30, Jim Meyering wrote:
>>> On Wed, Nov 23, 2016 at 5:22 AM, Marcel Böhme  
>>> wrote:
 Dear all,

 We are running small 1h fuzzing sessions with AFLFast, a fork of AFL.
 We’ll be reporting each found bug separately.

 On Coreutils v8.25 and trunk, the following input crashes.
 Option -n was introduced with v8.8.

 $ ./split -n7/75 7
 Segmentation fault

 ASAN says:
 =
 ==53143==ERROR: AddressSanitizer: negative-size-param: (size=-6)
 #0 0x7f8820eb9a10 in memmove 
 (/usr/lib/x86_64-linux-gnu/libasan.so.3+0x62a10)
 #1 0x404d12 in memmove /usr/include/x86_64-linux-gnu/bits/string3.h:57
 #2 0x404d12 in bytes_chunk_extract ../src/split.c:987
 #3 0x404d12 in main ../src/split.c:1625
 #4 0x7f881fd9cf44 in __libc_start_main 
 (/lib/x86_64-linux-gnu/libc.so.6+0x21f44)
 #5 0x4064a9  
 (/home/ubuntu/subjects/coreutils/obj-asan/src/split+0x4064a9)

 0x7f8821f9a006 is located 2054 bytes inside of 135168-byte region 
 [0x7f8821f99800,0x7f8821fba800)
 allocated by thread T0 here:
 #0 0x7f8820f193a8 in __interceptor_malloc 
 (/usr/lib/x86_64-linux-gnu/libasan.so.3+0xc23a8)
 #1 0x40ec88 in xmalloc ../lib/xmalloc.c:41

 SUMMARY: AddressSanitizer: negative-size-param 
 (/usr/lib/x86_64-linux-gnu/libasan.so.3+0x62a10) in memmove
>>>
>>> Thank you for the report.
>>> Would you please provide the contents of your file named "7"?
>>
>> That's immaterial I think. I can reproduce with:
>>   src/split -n2/3 /dev/null
>> I'll dig into these

Looks perfect.
Thanks!

bug#25004: Bug in OD utility

2016-11-23 Thread Marcel Böhme 
Hi Pádraig,

> On 24 Nov 2016, at 8:45 AM, Pádraig Brady  wrote:
> 
> I can't reproduce the issue here BTW with ASAN and running in a tight
> loop for a few minutes.  So perhaps it has been fixed in glibc already?
> I have glibc-2.22-10.fc23.x86_64
> Depending on how widespread the issue is will determine if it's worth
> adding the check to gnulib.

I can reproduce the crash on Ubuntu 14.04 x86_64 with preinstalled od version 
8.21 and the version in trunk.

> What libc are you using?

$ /lib/x86_64-linux-gnu/libc.so.6
GNU C Library (Ubuntu EGLIBC 2.19-0ubuntu6.9) stable release version 2.19, by 
Roland McGrath et al.
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 4.8.4.
Compiled on a Linux 3.13.11 system on 2016-05-26.
Available extensions:
crypt add-on version 2.1 by Michael Glad and others
GNU Libidn by Simon Josefsson
Native POSIX Threads Library by Ulrich Drepper et al
BIND-8.2.3-T5B
libc ABIs: UNIQUE IFUNC
For bug reporting instructions, please see:
.

bug#25004: Bug in OD utility

2016-11-23 Thread Pádraig Brady 
On 23/11/16 13:56, Marcel Böhme wrote:
> Dear all,
> 
> The following input crashes the od utility 3 out of 10 times. 
> Seems to depend on startup timing: Couldn’t reproduce it within GDB or 
> Valgrind. Not sure if its a bug in GNULIB (ftoastr.c) or OD (od.c).
> 
> $ printf "abcde\x00\x00\x00a " | od -tazfL -
> Segmentation fault
> 
> ASAN says:
> ==91757==ERROR: AddressSanitizer: SEGV on unknown address 0x (pc 
> 0x7f757ec161c0 bp 0x7ffc048a5ff0 sp 0x7ffc048a5208 T0)
> #0 0x7f757ec161bf  (/lib/x86_64-linux-gnu/libc.so.6+0x4f1bf)
> #1 0x7f757ec16e77 in __printf_fp (/lib/x86_64-linux-gnu/libc.so.6+0x4fe77)
> #2 0x7f757ec156d2 in vfprintf (/lib/x86_64-linux-gnu/libc.so.6+0x4e6d2)
> #3 0x7f757ecd0164 in __vsnprintf_chk 
> (/lib/x86_64-linux-gnu/libc.so.6+0x109164)
> #4 0x7f757ecd00c7 in __snprintf_chk 
> (/lib/x86_64-linux-gnu/libc.so.6+0x1090c7)
> #5 0x40ce1a in snprintf /usr/include/x86_64-linux-gnu/bits/stdio2.h:64
> #6 0x40ce1a in ldtoastr ../lib/ftoastr.c:131
> #7 0x408e69 in print_long_double ../src/od.c:479
> #8 0x40a2f1 in write_block ../src/od.c:1221
> #9 0x403eec in dump ../src/od.c:1436
> #10 0x403eec in main ../src/od.c:1978
> #11 0x7f757ebe8f44 in __libc_start_main 
> (/lib/x86_64-linux-gnu/libc.so.6+0x21f44)
> #12 0x405bd9  (/home/ubuntu/subjects/coreutils/obj-asan/src/od+0x405bd9)
> 
> AddressSanitizer can not provide additional info.
> SUMMARY: AddressSanitizer: SEGV (/lib/x86_64-linux-gnu/libc.so.6+0x4f1bf) 
> 
> This bug was found by AFLFast, a fork of AFL. Thanks also to Van-Thuan Pham!

Since coreutils-8.24 we have relied on gnulib to indicate
whether the system printf routines are safe to use (i.e. crash or not).

  http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=v8.23-81-gf57bfbb
  
http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=v8.23-176-gb817f62

It seems like we'll have to add another check to gnulib to detect
this issue in the system libs?

I can't reproduce the issue here BTW with ASAN and running in a tight
loop for a few minutes.  So perhaps it has been fixed in glibc already?
I have glibc-2.22-10.fc23.x86_64
Depending on how widespread the issue is will determine if it's worth
adding the check to gnulib.

What libc are you using?

thanks,
Pádraig

p.s. I tested od with AFL a lot on this system a while back
and didn't find any issues.

bug#25003: Bug in SPLIT utility

2016-11-23 Thread Pádraig Brady 
On 23/11/16 22:16, Pádraig Brady wrote:
> On 23/11/16 17:30, Jim Meyering wrote:
>> On Wed, Nov 23, 2016 at 5:22 AM, Marcel Böhme  
>> wrote:
>>> Dear all,
>>>
>>> We are running small 1h fuzzing sessions with AFLFast, a fork of AFL.
>>> We’ll be reporting each found bug separately.
>>>
>>> On Coreutils v8.25 and trunk, the following input crashes.
>>> Option -n was introduced with v8.8.
>>>
>>> $ ./split -n7/75 7
>>> Segmentation fault
>>>
>>> ASAN says:
>>> =
>>> ==53143==ERROR: AddressSanitizer: negative-size-param: (size=-6)
>>> #0 0x7f8820eb9a10 in memmove 
>>> (/usr/lib/x86_64-linux-gnu/libasan.so.3+0x62a10)
>>> #1 0x404d12 in memmove /usr/include/x86_64-linux-gnu/bits/string3.h:57
>>> #2 0x404d12 in bytes_chunk_extract ../src/split.c:987
>>> #3 0x404d12 in main ../src/split.c:1625
>>> #4 0x7f881fd9cf44 in __libc_start_main 
>>> (/lib/x86_64-linux-gnu/libc.so.6+0x21f44)
>>> #5 0x4064a9  
>>> (/home/ubuntu/subjects/coreutils/obj-asan/src/split+0x4064a9)
>>>
>>> 0x7f8821f9a006 is located 2054 bytes inside of 135168-byte region 
>>> [0x7f8821f99800,0x7f8821fba800)
>>> allocated by thread T0 here:
>>> #0 0x7f8820f193a8 in __interceptor_malloc 
>>> (/usr/lib/x86_64-linux-gnu/libasan.so.3+0xc23a8)
>>> #1 0x40ec88 in xmalloc ../lib/xmalloc.c:41
>>>
>>> SUMMARY: AddressSanitizer: negative-size-param 
>>> (/usr/lib/x86_64-linux-gnu/libasan.so.3+0x62a10) in memmove
>>
>> Thank you for the report.
>> Would you please provide the contents of your file named "7"?
> 
> That's immaterial I think. I can reproduce with:
>   src/split -n2/3 /dev/null
> I'll dig into these

Patch attached.

thanks!
Pádraig
>From 2ecc0890aa9fb182fe4362475d2d040607219cb1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?P=C3=A1draig=20Brady?= 
Date: Thu, 24 Nov 2016 00:03:16 +
Subject: [PATCH] split: fix memory corruption during chunk extraction

ASAN reported this error for: split -n2/3 /dev/null
  ERROR: AddressSanitizer: negative-size-param: (size=-1)
  #0 0x7f0d4c36951d in __asan_memmove (/lib64/libasan.so.2+0x8d51d)
  #1 0x404e06 in memmove /usr/include/bits/string3.h:59
  #2 0x404e06 in bytes_chunk_extract src/split.c:988
  #3 0x404e06 in main src/split.c:1626

Specifically there would be invalid memory access
and subsequent processing if the chunk to be extracted
was beyond the initial amount read from file (which is
currently capped at 128KiB).  This issue is not in a
released version, only being introduced in commit v8.25-4-g62e7af0

* src/split.c (bytes_chunk_extract): The initial_read != SIZE_MAX
should have been combined with && rather than ||, but also this
condition is always true in this function so remove entirely.
* tests/split/b-chunk.sh: Add a test case.

Fixes http://bugs.gnu.org/25003
---
 src/split.c| 2 +-
 tests/split/b-chunk.sh | 7 ++-
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/src/split.c b/src/split.c
index f9c99db..9a0704c 100644
--- a/src/split.c
+++ b/src/split.c
@@ -982,7 +982,7 @@ bytes_chunk_extract (uintmax_t k, uintmax_t n, char *buf, size_t bufsize,
   start = (k - 1) * (file_size / n);
   end = (k == n) ? file_size : k * (file_size / n);
 
-  if (initial_read != SIZE_MAX || start < initial_read)
+  if (start < initial_read)
 {
   memmove (buf, buf + start, initial_read - start);
   initial_read -= start;
diff --git a/tests/split/b-chunk.sh b/tests/split/b-chunk.sh
index 8475f96..c6619a2 100755
--- a/tests/split/b-chunk.sh
+++ b/tests/split/b-chunk.sh
@@ -25,9 +25,14 @@ split -n 10 /dev/null || fail=1
 test "$(stat -c %s x* | uniq -c | sed 's/^ *//; s/ /x/')" = "10x0" || fail=1
 rm -f x??
 
+# When extracting K of N where N > file size
+# no data is extracted, and no files are written
+split -n 2/3 /dev/null || fail=1
+returns_ 1 stat x?? 2>/dev/null || fail=1
+
 # Ensure --elide-empty-files is honored
 split -e -n 10 /dev/null || fail=1
-stat x?? 2>/dev/null && fail=1
+returns_ 1 stat x?? 2>/dev/null || fail=1
 
 printf '1\n2\n3\n4\n5\n' > input || framework_failure_
 
-- 
2.5.5

bug#25009: ls -b fails to escape '-' c-style (ls (GNU coreutils) 8.21)

2016-11-23 Thread Pádraig Brady 
On 23/11/16 23:34, Pádraig Brady wrote:
> On 23/11/16 23:27, Eric Blake wrote:
>> tag 25009 notabug
>> thanks
>>
>> On 11/23/2016 05:02 PM, Kay Parker wrote:
>>> ls -b  (ls (GNU coreutils) 8.21): fails to escape '-' 
>>> 1\ 2\ 3\ -\ 4\ -5\ 6
>>> should be: 1\ 2\ 3\ \-\ 4\ \-5\ 6
>>
>> Why? The documentation states:
>>
>>   -b, --escape   print C-style escapes for nongraphic characters
>>
>> but - looks like a graphical character to me, so it doesn't need an escape.
>>
>> I don't see a problem here, so I'm marking this as not a bug; however,
>> feel free to followup with more details, such as better justification
>> for why - should be treated as a nongraphic character.
> 
> Note you may be expecting ls to quote the file name
> so that it's subsequently usable as a parameter to a command.
> In that case --quoting=shell is more appropriate.

Actually 1\ -\ 2 is fine as a command parameter
(as the shell doesn't split it).
Sorry for the noise

bug#25009: ls -b fails to escape '-' c-style (ls (GNU coreutils) 8.21)

2016-11-23 Thread Pádraig Brady 
On 23/11/16 23:27, Eric Blake wrote:
> tag 25009 notabug
> thanks
> 
> On 11/23/2016 05:02 PM, Kay Parker wrote:
>> ls -b  (ls (GNU coreutils) 8.21): fails to escape '-' 
>> 1\ 2\ 3\ -\ 4\ -5\ 6
>> should be: 1\ 2\ 3\ \-\ 4\ \-5\ 6
> 
> Why? The documentation states:
> 
>   -b, --escape   print C-style escapes for nongraphic characters
> 
> but - looks like a graphical character to me, so it doesn't need an escape.
> 
> I don't see a problem here, so I'm marking this as not a bug; however,
> feel free to followup with more details, such as better justification
> for why - should be treated as a nongraphic character.

Note you may be expecting ls to quote the file name
so that it's subsequently usable as a parameter to a command.
In that case --quoting=shell is more appropriate.

bug#25009: ls -b fails to escape '-' c-style (ls (GNU coreutils) 8.21)

2016-11-23 Thread Eric Blake 
tag 25009 notabug
thanks

On 11/23/2016 05:02 PM, Kay Parker wrote:
> ls -b  (ls (GNU coreutils) 8.21): fails to escape '-' 
> 1\ 2\ 3\ -\ 4\ -5\ 6
> should be: 1\ 2\ 3\ \-\ 4\ \-5\ 6

Why? The documentation states:

  -b, --escape   print C-style escapes for nongraphic characters

but - looks like a graphical character to me, so it doesn't need an escape.

I don't see a problem here, so I'm marking this as not a bug; however,
feel free to followup with more details, such as better justification
for why - should be treated as a nongraphic character.

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

bug#25009: ls -b fails to escape '-' c-style (ls (GNU coreutils) 8.21)

2016-11-23 Thread Kay Parker 
ls -b  (ls (GNU coreutils) 8.21): fails to escape '-' 
1\ 2\ 3\ -\ 4\ -5\ 6
should be: 1\ 2\ 3\ \-\ 4\ \-5\ 6


-- 
  Kay Parker   
  kaypar...@mailite.com

-- 
http://www.fastmail.com - Does exactly what it says on the tin

bug#25003: Bug in SPLIT utility

2016-11-23 Thread Pádraig Brady 
On 23/11/16 17:30, Jim Meyering wrote:
> On Wed, Nov 23, 2016 at 5:22 AM, Marcel Böhme  wrote:
>> Dear all,
>>
>> We are running small 1h fuzzing sessions with AFLFast, a fork of AFL.
>> We’ll be reporting each found bug separately.
>>
>> On Coreutils v8.25 and trunk, the following input crashes.
>> Option -n was introduced with v8.8.
>>
>> $ ./split -n7/75 7
>> Segmentation fault
>>
>> ASAN says:
>> =
>> ==53143==ERROR: AddressSanitizer: negative-size-param: (size=-6)
>> #0 0x7f8820eb9a10 in memmove 
>> (/usr/lib/x86_64-linux-gnu/libasan.so.3+0x62a10)
>> #1 0x404d12 in memmove /usr/include/x86_64-linux-gnu/bits/string3.h:57
>> #2 0x404d12 in bytes_chunk_extract ../src/split.c:987
>> #3 0x404d12 in main ../src/split.c:1625
>> #4 0x7f881fd9cf44 in __libc_start_main 
>> (/lib/x86_64-linux-gnu/libc.so.6+0x21f44)
>> #5 0x4064a9  
>> (/home/ubuntu/subjects/coreutils/obj-asan/src/split+0x4064a9)
>>
>> 0x7f8821f9a006 is located 2054 bytes inside of 135168-byte region 
>> [0x7f8821f99800,0x7f8821fba800)
>> allocated by thread T0 here:
>> #0 0x7f8820f193a8 in __interceptor_malloc 
>> (/usr/lib/x86_64-linux-gnu/libasan.so.3+0xc23a8)
>> #1 0x40ec88 in xmalloc ../lib/xmalloc.c:41
>>
>> SUMMARY: AddressSanitizer: negative-size-param 
>> (/usr/lib/x86_64-linux-gnu/libasan.so.3+0x62a10) in memmove
> 
> Thank you for the report.
> Would you please provide the contents of your file named "7"?

That's immaterial I think. I can reproduce with:
  src/split -n2/3 /dev/null
I'll dig into these

bug#25003: Bug in SPLIT utility

2016-11-23 Thread Jim Meyering 
On Wed, Nov 23, 2016 at 5:22 AM, Marcel Böhme  wrote:
> Dear all,
>
> We are running small 1h fuzzing sessions with AFLFast, a fork of AFL.
> We’ll be reporting each found bug separately.
>
> On Coreutils v8.25 and trunk, the following input crashes.
> Option -n was introduced with v8.8.
>
> $ ./split -n7/75 7
> Segmentation fault
>
> ASAN says:
> =
> ==53143==ERROR: AddressSanitizer: negative-size-param: (size=-6)
> #0 0x7f8820eb9a10 in memmove 
> (/usr/lib/x86_64-linux-gnu/libasan.so.3+0x62a10)
> #1 0x404d12 in memmove /usr/include/x86_64-linux-gnu/bits/string3.h:57
> #2 0x404d12 in bytes_chunk_extract ../src/split.c:987
> #3 0x404d12 in main ../src/split.c:1625
> #4 0x7f881fd9cf44 in __libc_start_main 
> (/lib/x86_64-linux-gnu/libc.so.6+0x21f44)
> #5 0x4064a9  (/home/ubuntu/subjects/coreutils/obj-asan/src/split+0x4064a9)
>
> 0x7f8821f9a006 is located 2054 bytes inside of 135168-byte region 
> [0x7f8821f99800,0x7f8821fba800)
> allocated by thread T0 here:
> #0 0x7f8820f193a8 in __interceptor_malloc 
> (/usr/lib/x86_64-linux-gnu/libasan.so.3+0xc23a8)
> #1 0x40ec88 in xmalloc ../lib/xmalloc.c:41
>
> SUMMARY: AddressSanitizer: negative-size-param 
> (/usr/lib/x86_64-linux-gnu/libasan.so.3+0x62a10) in memmove

Thank you for the report.
Would you please provide the contents of your file named "7"?

bug#25003: Bug in SPLIT utility

2016-11-23 Thread Marcel Böhme 
Dear all,

We are running small 1h fuzzing sessions with AFLFast, a fork of AFL.
We’ll be reporting each found bug separately.

On Coreutils v8.25 and trunk, the following input crashes.
Option -n was introduced with v8.8.

$ ./split -n7/75 7
Segmentation fault

ASAN says:
=
==53143==ERROR: AddressSanitizer: negative-size-param: (size=-6)
#0 0x7f8820eb9a10 in memmove 
(/usr/lib/x86_64-linux-gnu/libasan.so.3+0x62a10)
#1 0x404d12 in memmove /usr/include/x86_64-linux-gnu/bits/string3.h:57
#2 0x404d12 in bytes_chunk_extract ../src/split.c:987
#3 0x404d12 in main ../src/split.c:1625
#4 0x7f881fd9cf44 in __libc_start_main 
(/lib/x86_64-linux-gnu/libc.so.6+0x21f44)
#5 0x4064a9  (/home/ubuntu/subjects/coreutils/obj-asan/src/split+0x4064a9)

0x7f8821f9a006 is located 2054 bytes inside of 135168-byte region 
[0x7f8821f99800,0x7f8821fba800)
allocated by thread T0 here:
#0 0x7f8820f193a8 in __interceptor_malloc 
(/usr/lib/x86_64-linux-gnu/libasan.so.3+0xc23a8)
#1 0x40ec88 in xmalloc ../lib/xmalloc.c:41

SUMMARY: AddressSanitizer: negative-size-param 
(/usr/lib/x86_64-linux-gnu/libasan.so.3+0x62a10) in memmove

Best regards,
- Marcel

bug#25004: Bug in OD utility

2016-11-23 Thread Marcel Böhme 
Dear all,

The following input crashes the od utility 3 out of 10 times. 
Seems to depend on startup timing: Couldn’t reproduce it within GDB or 
Valgrind. Not sure if its a bug in GNULIB (ftoastr.c) or OD (od.c).

$ printf "abcde\x00\x00\x00a " | od -tazfL -
Segmentation fault

ASAN says:
==91757==ERROR: AddressSanitizer: SEGV on unknown address 0x (pc 
0x7f757ec161c0 bp 0x7ffc048a5ff0 sp 0x7ffc048a5208 T0)
#0 0x7f757ec161bf  (/lib/x86_64-linux-gnu/libc.so.6+0x4f1bf)
#1 0x7f757ec16e77 in __printf_fp (/lib/x86_64-linux-gnu/libc.so.6+0x4fe77)
#2 0x7f757ec156d2 in vfprintf (/lib/x86_64-linux-gnu/libc.so.6+0x4e6d2)
#3 0x7f757ecd0164 in __vsnprintf_chk 
(/lib/x86_64-linux-gnu/libc.so.6+0x109164)
#4 0x7f757ecd00c7 in __snprintf_chk 
(/lib/x86_64-linux-gnu/libc.so.6+0x1090c7)
#5 0x40ce1a in snprintf /usr/include/x86_64-linux-gnu/bits/stdio2.h:64
#6 0x40ce1a in ldtoastr ../lib/ftoastr.c:131
#7 0x408e69 in print_long_double ../src/od.c:479
#8 0x40a2f1 in write_block ../src/od.c:1221
#9 0x403eec in dump ../src/od.c:1436
#10 0x403eec in main ../src/od.c:1978
#11 0x7f757ebe8f44 in __libc_start_main 
(/lib/x86_64-linux-gnu/libc.so.6+0x21f44)
#12 0x405bd9  (/home/ubuntu/subjects/coreutils/obj-asan/src/od+0x405bd9)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV (/lib/x86_64-linux-gnu/libc.so.6+0x4f1bf) 

This bug was found by AFLFast, a fork of AFL. Thanks also to Van-Thuan Pham!

Best regards,
- Marcel

bug#24996: Bug in PR utility

2016-11-23 Thread Paul Eggert 

Marcel Böhme wrote:

There is an integer overflow in pr.c:1880 which results in memory exhaustion. 
The bug was found with AFLFast, a fork of AFL.


Did it find only one such problem? I found half a dozen in the neighborhood. I 
guess it gave up after the first one. I fixed the bugs I found, by installing 
the attached patch. No doubt there are more bugs like this; please send more.
From e7f946e5b88455b76c21625dc1e3f73f4f9483c5 Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Wed, 23 Nov 2016 00:05:51 -0800
Subject: [PATCH] pr: fix integer overflow in buffer size calcs
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Problem reported by Marcel Böhme (Bug#24996).
* configure.ac (WERROR_CFLAGS): Avoid -Wtype-limits.
* src/pr.c (col_sep_string): Now a const pointer.  All uses changed.
(integer_overflow): New function.
(separator_string, main, init_parameters, init_store_cols):
Check for integer overflow.
(align_column, read_line, print_stored): Avoid integer overflow.
---
 configure.ac |  2 ++
 src/pr.c | 59 +--
 2 files changed, 39 insertions(+), 22 deletions(-)

diff --git a/configure.ac b/configure.ac
index a484601..1e74b36 100644
--- a/configure.ac
+++ b/configure.ac
@@ -132,6 +132,7 @@ if test "$gl_gcc_warnings" = yes; then
   nw="$nw -Wswitch-enum"# Too many warnings for now
   nw="$nw -Wswitch-default" # Too many warnings for now
   nw="$nw -Wstack-protector"# not worth working around
+  nw="$nw -Wtype-limits"# False alarms for portable code
   # things I might fix soon:
   nw="$nw -Wfloat-equal"# sort.c, seq.c
   nw="$nw -Wmissing-format-attribute" # copy.c
@@ -150,6 +151,7 @@ if test "$gl_gcc_warnings" = yes; then
 gl_WARN_ADD([$w])
   done
   gl_WARN_ADD([-Wno-sign-compare]) # Too many warnings for now
+  gl_WARN_ADD([-Wno-type-limits])  # False alarms for portable code
   gl_WARN_ADD([-Wno-unused-parameter]) # Too many warnings for now
   gl_WARN_ADD([-Wno-format-nonliteral])
 
diff --git a/src/pr.c b/src/pr.c
index 4e9d12e..20e8637 100644
--- a/src/pr.c
+++ b/src/pr.c
@@ -688,7 +688,7 @@ static bool use_col_separator = false;
 /* String used to separate columns if the -S option has been specified.
Default without -S but together with one of the column options
-a|COLUMN|-m is a 'space' and with the -J option a 'tab'. */
-static char *col_sep_string = (char *) "";
+static char const *col_sep_string = "";
 static int col_sep_length = 0;
 static char *column_separator = (char *) " ";
 static char *line_separator = (char *) "\t";
@@ -771,6 +771,12 @@ static struct option const long_options[] =
   {NULL, 0, NULL, 0}
 };
 
+static void
+integer_overflow (void)
+{
+  die (EXIT_FAILURE, 0, _("integer overflow"));
+}
+
 /* Return the number of columns that have either an open file or
stored lines. */
 
@@ -840,9 +846,11 @@ parse_column_count (char const *s)
 static void
 separator_string (const char *optarg_S)
 {
-  col_sep_length = (int) strlen (optarg_S);
-  col_sep_string = xmalloc (col_sep_length + 1);
-  strcpy (col_sep_string, optarg_S);
+  size_t len = strlen (optarg_S);
+  if (INT_MAX < len)
+integer_overflow ();
+  col_sep_length = len;
+  col_sep_string = optarg_S;
 }
 
 int
@@ -869,7 +877,7 @@ main (int argc, char **argv)
 
   n_files = 0;
   file_names = (argc > 1
-? xmalloc ((argc - 1) * sizeof (char *))
+? xnmalloc (argc - 1, sizeof (char *))
 : NULL);
 
   while (true)
@@ -1000,7 +1008,7 @@ main (int argc, char **argv)
 case 'S':
   old_s = false;
   /* Reset an additional input of -s, -S dominates -s */
-  col_sep_string = bad_cast ("");
+  col_sep_string = "";
   col_sep_length = 0;
   use_col_separator = true;
   if (optarg)
@@ -1262,8 +1270,13 @@ init_parameters (int number_of_files)
 chars_used_by_number = number_width;
 }
 
-  chars_per_column = (chars_per_line - chars_used_by_number
-  - (columns - 1) * col_sep_length) / columns;
+  int sep_chars, useful_chars;
+  if (INT_MULTIPLY_WRAPV (columns - 1, col_sep_length, &sep_chars))
+sep_chars = INT_MAX;
+  if (INT_SUBTRACT_WRAPV (chars_per_line - chars_used_by_number, sep_chars,
+  &useful_chars))
+useful_chars = 0;
+  chars_per_column = useful_chars / columns;
 
   if (chars_per_column < 1)
 die (EXIT_FAILURE, 0, _("page width too narrow"));
@@ -1714,7 +1727,7 @@ static void
 align_column (COLUMN *p)
 {
   padding_not_printed = p->start_position;
-  if (padding_not_printed - col_sep_length > 0)
+  if (col_sep_length < padding_not_printed)
 {
   pad_across_to (padding_not_printed - col_sep_length);
   padding_not_printed = ANYWHERE;
@@ -1877,21 +1890,25 @@ print_page (void)
 static void
 init_store_cols (void)
 {
-  int total_lines = lines_per_body * columns;
-  int cha