Re: SHLVL is a random string (uninitialized string in C) when its true value is "1000"
On 9/17/15 12:29 AM, ziyunfei wrote: > $ SHLVL=998 bash -c 'echo $SHLVL' > 999 > $ SHLVL=999 bash -c 'echo $SHLVL' > > $ SHLVL=999 bash -c 'echo -n "$SHLVL" | hexdump' > 0b 01 > $ SHLVL=999 bash -c 'echo -n "$SHLVL" | hexdump' > 0f 01 > $ SHLVL=999 bash -c 'echo -n "$SHLVL" | hexdump' > 04 01 > $ SHLVL=1000 bash -c 'echo $SHLVL' > bash: warning: shell level (1001) too high, resetting to 1 > 1 Thanks for the report. That bug is old enough to vote in the US. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
4-byte script triggers null ptr deref and segfault
While fuzzing GNU bash version 4.3.42(1)-release (x86_64-unknown-linux-gnu) with AFL(http://lcamtuf.coredump.cx/afl), I stumbled upon a 4-byte 'script' that triggers a null ptr deref and causes a segfault. https://savannah.gnu.org/support/index.php?108885
Re: 4-byte script triggers null ptr deref and segfault
On Thu, Sep 17, 2015 at 11:50:44AM -0500, Brian Carpenter wrote: > While fuzzing GNU bash version 4.3.42(1)-release > (x86_64-unknown-linux-gnu) with AFL(http://lcamtuf.coredump.cx/afl), I > stumbled upon a 4-byte 'script' that triggers a null ptr deref and causes a > segfault. > > https://savannah.gnu.org/support/index.php?108885 Well, that's an annoying web-to-mail interface. It didn't include the full bug report? The web page says the hexdump of the attached script is 3b21 2620 which I would normally interpret as `;!& '. But the attached script itself is actually `!; &'. Apparently the hex dump tool in question is doing some sort of 16-bit grouping with little endian byte swapping. After getting the correct content into the script, I can reproduce this on HP-UX in 4.3.39: imadev:~$ printf '!; &' > x imadev:~$ bash x Segmentation fault (core dumped)
Re: 4-byte script triggers null ptr deref and segfault
On 17/09/15 18:20, Greg Wooledge wrote: > On Thu, Sep 17, 2015 at 11:50:44AM -0500, Brian Carpenter wrote: >> While fuzzing GNU bash version 4.3.42(1)-release >> (x86_64-unknown-linux-gnu) with AFL(http://lcamtuf.coredump.cx/afl), I >> stumbled upon a 4-byte 'script' that triggers a null ptr deref and causes a >> segfault. >> >> https://savannah.gnu.org/support/index.php?108885 > > Well, that's an annoying web-to-mail interface. It didn't include the > full bug report? > > The web page says the hexdump of the attached script is 3b21 2620 > which I would normally interpret as `;!& '. > > But the attached script itself is actually `!; &'. Apparently the > hex dump tool in question is doing some sort of 16-bit grouping with > little endian byte swapping. > > After getting the correct content into the script, I can reproduce > this on HP-UX in 4.3.39: > > imadev:~$ printf '!; &' > x > imadev:~$ bash x > Segmentation fault (core dumped) FWIW _not_ reproduced with bash-4.3.39-1.fc22.x86_64
Re: 4-byte script triggers null ptr deref and segfault
Greg Wooledge wrote: > Brian Carpenter wrote: > > While fuzzing GNU bash version 4.3.42(1)-release > > (x86_64-unknown-linux-gnu) with AFL(http://lcamtuf.coredump.cx/afl), I > > stumbled upon a 4-byte 'script' that triggers a null ptr deref and causes a > > segfault. > > > > https://savannah.gnu.org/support/index.php?108885 > > Well, that's an annoying web-to-mail interface. It didn't include the > full bug report? There is no web-to-mail interface. The above was simply an email from Brian citing the bug report he filed above. He filed a ticket on the web site and then mailed a reference to it here. Bob
Re: 4-byte script triggers null ptr deref and segfault
On 9/17/15 12:50 PM, Brian Carpenter wrote: > While fuzzing GNU bash version 4.3.42(1)-release > (x86_64-unknown-linux-gnu) with AFL(http://lcamtuf.coredump.cx/afl), I > stumbled upon a 4-byte 'script' that triggers a null ptr deref and causes a > segfault. > > https://savannah.gnu.org/support/index.php?108885 Thanks for the report. This was fixed late last October, and the fix is in the devel branch and bash-4.4-alpha. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: null ptr deref & segfault in multiple versions of bash
On 9/16/15 10:41 PM, Brian Carpenter wrote: > <<$(()())|>_[$($(<<0)) triggers a null ptr deref and segfault in multiple > versions of bash > > https://savannah.gnu.org/support/index.php?108884 Thanks for the report. This will be fixed in the next release of bash. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: [Help-bash] Why BASH_SUBSHELL behaves differently in () and <()?
> The expansion is being done in the parent shell, rather than the subshell. But as you said in http://lists.gnu.org/archive/html/help-bash/2015-04/msg00010.html BASHPID is expanded in the subshell, so BASH_SUBSHELL must also be like that. And I found a comment which says: "make the child early, before word expansion" at http://code.metager.de/source/xref/gnu/bash/execute_cmd.c#3922
indirection on '$1, $2...' ?
Is it documented that ${!1} won't give you indirection
of "$1"? I guess I missed that, and sorta expected it
to do indirection the same as any other var, but doesn't
seem to work in 4.3.39.
Should it? Or why shouldn't it?
tnx...
-l
Re: indirection on '$1, $2...' ?
Never mind for now... there obviously something
else going on ... (had problems w/it buried in
a function, but in simple echo test, works fine...)
so ... likely operator error...so please ignore this
until I figure out a proper example...(which I'm not
assuming I will -- i.e. more likely some other problem)...
sorry for line noise.
Linda Walsh wrote:
Is it documented that ${!1} won't give you indirection
of "$1"? I guess I missed that, and sorta expected it
to do indirection the same as any other var, but doesn't
seem to work in 4.3.39.
Should it? Or why shouldn't it?
tnx...
-l
