Improper array name validation for the 'mapfile' builtin

Hi Chet, It seems like the variable name validation for the mapfile builtin is a bit wrong. I hope the patch below fixes it. Demonstration: | dualbus@hp ...local/src/bash % : before patch | dualbus@hp ...local/src/bash % /bin/bash -c 'mapfile -t "a[\$(ls)]" <<< ""; declare -p'|grep -F '[$(' | d

Re: CVE-2014-7187 and CVE-2014-6278

2014-11-17 08:49:59 -0500, Greg Wooledge: [...] > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6278 is the > REAL bug. This is the root cause of all the remote exploitation > badness. The patches which fix this problem fix remote exploitation > of ALL the dumb parser bugs by closing of

Re: CVE-2014-7187 and CVE-2014-6278

On Mon, Nov 17, 2014 at 04:22:53PM +, Stephane Chazelas wrote: > The real bug doesn't have a CVE attached to it because it's not > a vulnerability or bug. It was "allowing the bash parser to be > exposed to untrusted data", more a very unsafe design that was > allowing any minor bug to turn int

Re: CVE-2014-7187 and CVE-2014-6278

On Mon, Nov 17, 2014 at 04:30:07PM +0800, Jack wrote: > As title, what difference between CVE-2014-7187 and CVE-2014-6278 ? https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-7187 says "Off-by-one error in the read_token_word function in parse.y" So it's just another dumb parser bug, nothing

CVE-2014-7187 and CVE-2014-6278

As title, what difference between CVE-2014-7187 and CVE-2014-6278 ? In CVE-2014-7187 says, the test case is probe='() { echo vulnerable; }' bash -c probe but in Shellshocker CVE-2014-6278 , bot

Segmentation fault when running recursive traps

I know that a recursive trap in a script is probably a bug, but I think that it shouldn't make bash segfault: | dualbus@hp ...local/src/bash % ./bash -c 'trap "kill \$\$" TERM; kill $$' | [...] | ./bash: line 1: warning: run_pending_traps: recursive invocation while running trap for signal 15 | .