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
> $
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
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://savanna
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
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.o
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/ind
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, t
> 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,
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
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 oth
10 matches
Mail list logo