GNU bug report logs -
#16855
report a bug about shuf
Previous Next
Reported by: valiant xiao <s2exqx <at> gmail.com>
Date: Sun, 23 Feb 2014 18:59:03 UTC
Severity: normal
Done: Paul Eggert <eggert <at> cs.ucla.edu>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 16855 in the body.
You can then email your comments to 16855 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-coreutils <at> gnu.org
:
bug#16855
; Package
coreutils
.
(Sun, 23 Feb 2014 18:59:03 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
valiant xiao <s2exqx <at> gmail.com>
:
New bug report received and forwarded. Copy sent to
bug-coreutils <at> gnu.org
.
(Sun, 23 Feb 2014 18:59:03 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi,
We have found a bug in shuf, and we think it may be result a security
problem.
we compile coreutils 8.22 which is download from
http://ftp.gnu.org/gnu/coreutils/, and run it on
my box that is ubuntu 12.04 x64. the bug details as follows.
### Bug overview
shuf -er or shuf -eer [ segment fault]
impact [coreutils 8.22 ]
```
[15:03:59]xqx <at> server:~/data/xqx/projects/coreutils-8.22$
./obj-gcov/src/shuf -er
Segmentation fault (core dumped)
```
### Analysis
when shuf execute -e without give the expected input lines, it will
assign n_lines to 0 in "write_random_lines" while the "repeat" (-r) be set.
and this var will be as the genmax parameter when "randint_genmax" function
called. the code as follows in shuf.c:
```
369 for (i = 0; i < count; i++)
370 {
371 const randint j = randint_choose (s, n_lines);
372 char *const *p = lines + j;
373 size_t len = p[1] - p[0];
374 if (fwrite (p[0], sizeof *p[0], len, stdout) != len)
375 return -1;
376 }
377
```
'j' will be a random number between 0-0xffffffffffffffff in my 64bit
ubuntu, and 'p' will be a unexpected point which will be access next. when
p point to an ilegal memory, it will be error when access it, which may be
result in a Segmentation fault.
if an attacker could control the random which gened by randint_choose,
it may be get the infomation without an legal authority. However, It may
be difficult.
yours
xqx
[Message part 2 (text/html, inline)]
Reply sent
to
Paul Eggert <eggert <at> cs.ucla.edu>
:
You have taken responsibility.
(Sun, 23 Feb 2014 23:38:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
valiant xiao <s2exqx <at> gmail.com>
:
bug acknowledged by developer.
(Sun, 23 Feb 2014 23:38:03 GMT)
Full text and
rfc822 format available.
Message #10 received at 16855-done <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Thanks for the bug report. I've committed the attached patch.
[shuf.diff (text/plain, attachment)]
Information forwarded
to
bug-coreutils <at> gnu.org
:
bug#16855
; Package
coreutils
.
(Mon, 24 Feb 2014 01:05:02 GMT)
Full text and
rfc822 format available.
Message #13 received at 16855 <at> debbugs.gnu.org (full text, mbox):
On 02/23/2014 11:37 PM, Paul Eggert wrote:
> Thanks for the bug report. I've committed the attached patch.
>
> shuf.diff
>
>
> From 24eb395471176e24762b08bfcef7562911537504 Mon Sep 17 00:00:00 2001
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Sun, 23 Feb 2014 15:34:48 -0800
> Subject: [PATCH] shuf: with -r, don't dump core if the input is empty
>
> Problem reported by valiant xiao in <http://bugs.gnu.org/16855>.
> * NEWS: Document this.
> * src/shuf.c (main): With -r, report an error if the input is empty.
> * tests/misc/shuf.sh: Test for the bug.
> ---
> NEWS | 3 +++
> src/shuf.c | 15 +++++++++++----
> tests/misc/shuf.sh | 4 ++++
> 3 files changed, 18 insertions(+), 4 deletions(-)
>
> diff --git a/NEWS b/NEWS
> index e72942b..2df246d 100644
> --- a/NEWS
> +++ b/NEWS
> @@ -22,6 +22,9 @@ GNU coreutils NEWS -*- outline -*-
> it would display an error, requiring --no-dereference to avoid the issue.
> [bug introduced in coreutils-5.3.0]
>
> + shuf -r no longer dumps core if the input is empty.
> + [bug introduced in coreutils-8.22]
> +
> ** New features
>
> od accepts a new option: --endian=TYPE to handle inputs with different byte
> diff --git a/src/shuf.c b/src/shuf.c
> index d4641fe..2a91072 100644
> --- a/src/shuf.c
> +++ b/src/shuf.c
> @@ -576,11 +576,18 @@ main (int argc, char **argv)
> /* Generate output according to requested method */
> if (repeat)
> {
> - if (input_range)
> - i = write_random_numbers (randint_source, head_lines,
> - lo_input, hi_input, eolbyte);
> + if (head_lines == 0)
> + i = 0;
> else
> - i = write_random_lines (randint_source, head_lines, line, n_lines);
> + {
> + if (n_lines == 0)
> + error (EXIT_FAILURE, 0, _("No lines to repeat"));
Thanks for the quick fix.
I was wondering if we do want to error if there is no input,
rather than silently exit(0)?
$ shuf -r -n1 /dev/null
shuf: No lines to repeat
I guess that makes sense since we can't fulfil the request
to repeat forever, or with -n; at least up to n.
I.E. rather than this being a transformation of the input,
the input in insufficient to generate the requested output.
thanks,
Pádraig.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Mon, 24 Mar 2014 11:24:04 GMT)
Full text and
rfc822 format available.
This bug report was last modified 10 years and 6 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.