Re: Segmentation fault in expassign when PS1='$[U[0S]+=]'

2017-05-16 Thread Chet Ramey
On 5/15/17 3:58 PM, Eduardo Bustamante wrote:

> bash-4.4$ "$[U[0S]+=]"
> bash: 0S: value too great for base (error token is "0S")
> 
> It seems like the array index expression causes a longjmp in the
> second case, so it stops evaluating.
> 
> Found by fuzzing.
> 
> I think this might be similar to
> https://lists.gnu.org/archive/html/bug-bash/2017-05/msg00046.html
> (i.e. ``Segmentation fault in evalerror when xtrace and
> PS4='$[T[$]]'``)
> 
> I think the fix *may* be something like:

You're on the right track. Thanks for the report.

Chet

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/



Segmentation fault in expassign when PS1='$[U[0S]+=]'

2017-05-15 Thread Eduardo Bustamante
Starting program: /home/dualbus/src/gnu/bash/bash
bash-4.4$ PS1='$[U[0S]+=]'
bash: 0S: value too great for base (error token is "0S")
bash: : syntax error in expression (error token is "U")
$[U[0S]+=]
bash: 0S: value too great for base (error token is "0S")

Program received signal SIGSEGV, Segmentation fault.
strlen () at ../sysdeps/x86_64/strlen.S:106
106 ../sysdeps/x86_64/strlen.S: No such file or directory.
(gdb) bt
#0  strlen () at ../sysdeps/x86_64/strlen.S:106
#1  0x555b1ff7 in expassign () at expr.c:505
#2  0x555b1f4b in expcomma () at expr.c:467
#3  0x555b1ec2 in subexpr (expr=0x5596a148 "U[0S]+=") at expr.c:449
#4  0x555b1d51 in evalexp (expr=0x5596a148 "U[0S]+=",
flags=1, validp=0x7fffbff0) at expr.c:414
#5  0x555d0a73 in param_expand (string=0x5596a0a8
"$[U[0S]+=]", sindex=0x7fffc0e8, quoted=1, expanded_something=0x0,
contains_dollar_at=0x7fffc0dc,
quoted_dollar_at_p=0x7fffc0e4, had_quoted_null_p=0x7fffc0e0,
pflags=0) at subst.c:9159
#6  0x555d1c27 in expand_word_internal (word=0x7fffc1f0,
quoted=1, isexp=0, contains_dollar_at=0x0,
expanded_something=0x0) at subst.c:9655
#7  0x555c4c79 in expand_prompt_string (string=0x5596a188
"$[U[0S]+=]", quoted=1, wflags=0) at subst.c:3785
#8  0x555934b7 in decode_prompt_string (string=0x5596a393
"\v") at ./parse.y:5961
#9  0x55592479 in prompt_again () at ./parse.y:5472
#10 0x5558ab70 in yylex () at ./parse.y:2677
#11 0x55585e34 in yyparse () at y.tab.c:1821
#12 0x55585772 in parse_command () at eval.c:294
#13 0x55585858 in read_command () at eval.c:338
#14 0x555853b1 in reader_loop () at eval.c:140
#15 0x55582f71 in main (argc=1, argv=0x7fffe478,
env=0x7fffe488) at shell.c:794

(gdb) frame 1
#1  0x555b1ff7 in expassign () at expr.c:505
505   lhs = savestring (tokstr);
(gdb) p tokstr
$5 = 0x0

I still don't understand why this isn't triggered by:

bash-4.4$ "$[U[0S]+=]"
bash: 0S: value too great for base (error token is "0S")

It seems like the array index expression causes a longjmp in the
second case, so it stops evaluating.

Found by fuzzing.

I think this might be similar to
https://lists.gnu.org/archive/html/bug-bash/2017-05/msg00046.html
(i.e. ``Segmentation fault in evalerror when xtrace and
PS4='$[T[$]]'``)

I think the fix *may* be something like:

dualbus@debian:~/src/gnu/bash$ git diff -- expr.c
diff --git a/expr.c b/expr.c
index 1770cc00..d6c50571 100644
--- a/expr.c
+++ b/expr.c
@@ -494,6 +494,8 @@ expassign ()

   if (lasttok != STR)
evalerror (_("attempted assignment to non-variable"));
+  if (!tokstr)
+   evalerror (_("XXX"));

   if (special)
{

But I don't know.