bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Segfault when closing piped stdin on 4.4.11


From: Eduardo Bustamante
Subject: Re: Segfault when closing piped stdin on 4.4.11
Date: Mon, 15 May 2017 23:01:29 -0500

On Mon, May 15, 2017 at 8:09 PM, Elliott Cable <me@ell.io> wrote:
> I'm no shell-script master, but this is segfaulting my Bash, and I was
> able to reproduce it on a couple different systems (including the #bash
> shbot :P):
>
>     echo '_() { exec <&- ;}; _ "$0" "$@"' >bleh.sh
>     cat bleh.sh | bash

It's worth noting that this was fixed in the `devel' branch as a
result of the following report:
https://lists.gnu.org/archive/html/bug-bash/2017-03/msg00088.html

dualbus@debian:~/src/gnu/bash$ ./bash <<< 'exec <&-'
Segmentation fault (core dumped)

[New LWP 7237]
Core was generated by `./bash'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x0000563a97cb9b2b in buffered_getchar () at input.c:565
565       return (bufstream_getc (buffers[bash_input.location.buffered_fd]));
(gdb) bt
#0  0x0000563a97cb9b2b in buffered_getchar () at input.c:565
#1  0x0000563a97c6d23a in yy_getc () at
/usr/homes/chet/src/bash/src/parse.y:1390
#2  0x0000563a97c6e12b in shell_getc (remove_quoted_newline=1) at
/usr/homes/chet/src/bash/src/parse.y:2299
#3  0x0000563a97c6f654 in read_token (command=0) at
/usr/homes/chet/src/bash/src/parse.y:3115
#4  0x0000563a97c6ebed in yylex () at /usr/homes/chet/src/bash/src/parse.y:2675
#5  0x0000563a97c6a251 in yyparse () at y.tab.c:1834
#6  0x0000563a97c69ecd in parse_command () at eval.c:261
#7  0x0000563a97c69fb3 in read_command () at eval.c:305
#8  0x0000563a97c69bf7 in reader_loop () at eval.c:149
#9  0x0000563a97c677fa in main (argc=1, argv=0x7ffd0dc0b498,
env=0x7ffd0dc0b4a8) at shell.c:792

(gdb) p bash_input.location.buffered_fd
$1 = 0
(gdb) p buffers[0]
$2 = (BUFFERED_STREAM *) 0x0

i.e. the problem is that the `exec <&-' closes stdin, which is the
file descriptor bash is using to read the code. So the parser tries to
read more code, and ends up dereferencing a NULL pointer.

Commit f698849a75fc781472806182c3dc930077a5d828 in the `devel' branch
adds the NULL pointer check to bufstream_ungetc (`bp == 0') before
dereferencing the `bp' pointer.

dualbus@debian:~/src/gnu/bash$ git show
f698849a75fc781472806182c3dc930077a5d828 -- input.c
commit f698849a75fc781472806182c3dc930077a5d828
Author: Chet Ramey <chet.ramey@case.edu>
Date:   Mon Mar 20 16:30:10 2017 -0400

    commit bash-20170317 snapshot

diff --git a/input.c b/input.c
index ffd0c4b8..6d0e6871 100644
--- a/input.c
+++ b/input.c
@@ -525,7 +525,7 @@ bufstream_ungetc(c, bp)
      int c;
      BUFFERED_STREAM *bp;
 {
-  if (c == EOF || bp->b_inputp == 0)
+  if (c == EOF || bp == 0 || bp->b_inputp == 0)
     return (EOF);

   bp->b_buffer[--bp->b_inputp] = c;
@@ -556,6 +556,9 @@ buffered_getchar ()
 {
   CHECK_TERMSIG;

+  if (bash_input.location.buffered_fd < 0 ||
buffers[bash_input.location.buffered_fd] == 0)
+    return EOF;
+
 #if !defined (DJGPP)
   return (bufstream_getc (buffers[bash_input.location.buffered_fd]));
 #else



reply via email to

[Prev in Thread] Current Thread [Next in Thread]