Dear all,
During fuzzing, we found one use-after-free in tac and one
invalid-loading-of-value in tail.
Interestingly, these errors can be observed only when stdin is externally
closed but internally expected to be open.
The bugs were found by AFLFast, a fork of AFL.
The bug in tac was also fou
Dear all,
The following execution is flagged by UBSAN as undefined behaviour:
$ echo 0 > a; printf "%0.s0" {1..58} >> a
$ ./sort -R a
UBSAN says:
../lib/md5.c:371:7: runtime error: load of misaligned address 0x7ffdfd45a10d
for type 'const uint32_t', which requires 4 byte alignment
So, the roo
Dear all,
The following input to PR does not crash the program but ASAN reports a buffer
overflow.
The bug was found with AFLFast, a fork of AFL. Thanks also to Van-Thuan Pham.
$ echo a > a
$ pr "-S$(printf "\t\t\t")" a -m a > /dev/null
==
Dear all,
The following produces a crash for the version in trunk and preinstalled
version 8.21 on Ubuntu 14.04 x86_64.
Below is also heap-buffer-overflow that doesn’t actually crash but is flagged
by ASAN as an invalid read of size 1.
Both bugs were found by AFLFast, a fork of AFL. Thanks goes
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 de
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:
=
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=
Dear all,
There is an integer overflow in pr.c:1880 which results in memory exhaustion.
The bug was found with AFLFast, a fork of AFL.
How to reproduce:
$ pr -l -5
I was actually fuzzing Coreutils 6.10 as part of ongoing experiments.
Also confirmed for Coreutils 8.25.
Best regards,
- M
Dear all,
The current version of cut (after 6.12.2012) exposes a SEG_FAULT:
$echo 123 | cut --output-del="." -b-1,9-
How the commit introduces the bug:
Earlier, memory of length eol_start_length was allocated for the array
printable_field - if max_range_endpoint < eol_star
Dear all,
I've been looking into the semantic changes introduced to printf with the
commit 62e1d5259df82155ae52201678093381a35d898e (08.07.2004) and found besides
a lot of progression (conformance to C99 etc.) the following oddities:
The tool printf ignores length modifiers (cf. http://linux.di
Dear all,
There is another bug that sneaked into the speed patch of seq on 13.09.12:
560 if (all_digits_p (argv[optind])
561 && (n_args == 1 || all_digits_p (argv[optind + 1]))
562 && (n_args < 3 || STREQ ("1", argv[optind + 2]))
563 && !equal_width && !format_str && strlen (
Dear all,
There are the following problems with the -w parameter of the seq tool:
$seq -w -1 1.0 0
-1.0
0.0
1.0
But it should print:
-1.0
00.0
01.0
A similar problem is observable for:
$seq -w 10 -.1 1 | head
Best regards,
Marcel
Hi,
I found two (semantically related) bugs. One seems to originate in the
first version. For research purposes, I would appreciate if you could
confirm that the second was introduced with Coreutils 5.3.0.
1) The following bug seems to exists "since the beginning".
$echo 123456789
| tail -2
9
10
$ seq -w -1e-1 1
-00.1
000.9
$ seq -w -0.1 1
-0.1
00.9
Thanks!
Best regards,
Marcel
On 11/22/2012 11:58 AM, Pádraig Brady wrote:
On 11/22/2012 10:49 AM, Marcel Böhme wrote:
> Hi,
>
> While the output of (1) "seq -w -1e-2 9" prints the width as expecte
Hi,
While the output of (1) "seq -w -1e-2 9" prints the width as expected, the
output of (2) "seq -w -1e-3 9" does not:
(1) vs. (2)
-0.01 | -0.001
00.99 | 0.999
01.99 | 1.999
02.99 | 2.999
03.99 | 3.999
04.99 | 4.999
05.99 | 5.999
06.99 | 6.999
07.99 | 7.999
08.99 | 8.999
Similarly, see "seq -w
Hi,
This is no bug per se. Apparently, the deprecated option
--page-increment for the tool "nl" has been scheduled to be removed on
Dec. 2011 :)
Line 160: /* FIXME: page-increment is deprecated, remove in dec-2011.
*/
See
http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a
Hi,
The command "echo 12345 | cut -b 0-" prints an empty line while it
should fail with "fields and positions are numbered from 1" according
to this specification "cut: diagnose a range starting with 0 (-f 0-2)
as invalid".
Can you confirm this is an incomplete bugfix made on 2007
17 matches
Mail list logo
