Reproducible SIGSEGV in bash 4.2 caused by alias.
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL
-DHAVE_CONFIG_H -I. -I../bash -I../bash/include -I../bash/lib
-D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat
-Werror=format-security -Wall
uname output: Linux SANITIZED 3.11.0-11-generic #17-Ubuntu SMP Tue Oct 1
19:42:04 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Bash Version: 4.2
Patch Level: 45
Release Status: release
Description:
Playing around with aliases, I stumbled over the following:
$ alias alias="eval alias"
$ alias foo=bar
[CRASH]
Last lines of an attached strace:
[...]
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
brk(0x413) = 0x413
brk(0x4131000) = 0x4131000
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
brk(0x4132000) = 0x4132000
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x7fffc6f2aff8} ---
--- SIGSEGV {si_signo=SIGSEGV, si_code=SI_KERNEL, si_addr=0} ---
+++ killed by SIGSEGV (core dumped) +++
Applies to 32 & 64 Bit Version.
Repeat-By:
Just type
$ alias alias="eval alias"
$ alias foo=bar
Re: Reproducible SIGSEGV in bash 4.2 caused by alias.
"Oliver J. Morais" writes:
> Playing around with aliases, I stumbled over the following:
> $ alias alias="eval alias"
> $ alias foo=bar
You have created an infinite recursion, same as f() { f; }; f.
Andreas.
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
Re: Reproducible SIGSEGV in bash 4.2 caused by alias.
[Thu, Oct 10, 2013 at 11:38:47AM +0200] Andreas Schwab
> "Oliver J. Morais" writes:
> > Playing around with aliases, I stumbled over the following:
> > $ alias alias="eval alias"
> > $ alias foo=bar
> You have created an infinite recursion, same as f() { f; }; f.
Sure, but I think bash should not just crash, zsh for example catches
this glitch:
% alias alias="eval alias"
% alias foo=bar
zsh: job table full or recursion limit exceeded
I know, bash != zsh and the eval-alias-foo is a silly thing to do,
but crashing is a bug :)
Re: Reproducible SIGSEGV in bash 4.2 caused by alias.
helo all!
I agree, it is abit off a bug. That should fix it (coding and writting from
my mobile, so sorry for bad style ;-)) :
cheers,
pg
---
builtins/alias.def | 7 +++
1 file changed, 7 insertions(+)
diff --git a/builtins/alias.def b/builtins/alias.def
index d760ceb..7a7b510 100644
--- a/builtins/alias.def
+++ b/builtins/alias.def
@@ -67,6 +67,9 @@ static void print_alias __P((alias_t *, int));
extern int posixly_correct;
+#define MAX_RECURSIONS 255
+static int recursion_count=0;
+
/* Hack the alias command in a Korn shell way. */
int
alias_builtin (list)
@@ -76,6 +79,10 @@ alias_builtin (list)
alias_t **alias_list, *t;
char *name, *value;
+ if (recursion_count>MAX_RECURSIONS) {
+ return EXECUTION_FAILURE;
+ }
+ recursion_count++;
dflags = posixly_correct ? 0 : AL_REUSABLE;
pflag = 0;
reset_internal_getopt ();
--
1.8.4
On Oct 10, 2013 11:50 AM, "Oliver J. Morais"
wrote:
>
> [Thu, Oct 10, 2013 at 11:38:47AM +0200] Andreas Schwab
> > "Oliver J. Morais" writes:
> > > Playing around with aliases, I stumbled over the following:
> > > $ alias alias="eval alias"
> > > $ alias foo=bar
> > You have created an infinite recursion, same as f() { f; }; f.
>
> Sure, but I think bash should not just crash, zsh for example catches
> this glitch:
>
> % alias alias="eval alias"
> % alias foo=bar
> zsh: job table full or recursion limit exceeded
>
> I know, bash != zsh and the eval-alias-foo is a silly thing to do,
> but crashing is a bug :)
>
Re: Reproducible SIGSEGV in bash 4.2 caused by alias.
a small correction, if I may; while that was all very sweet, there
are two issues here:
1. recursion_count has to be reset somewhere, or else it is a global
alias limit :)
2. a better place for this limit is acctually eval (probably leaving
alias recursion limit, before Oliver starts playing with it, is also a
good idea?):
---
builtins/eval.def | 9 +
1 file changed, 9 insertions(+)
diff --git a/builtins/eval.def b/builtins/eval.def
index 5e824c9..63b338b 100644
--- a/builtins/eval.def
+++ b/builtins/eval.def
@@ -44,11 +44,20 @@ $END
#include "bashgetopt.h"
#include "common.h"
+#define MAX_RECURSIONS 255
+static int recursion_count=0;
+
/* Parse the string that these words make, and execute the command found. */
int
eval_builtin (list)
WORD_LIST *list;
{
+ if (recursion_count>MAX_RECURSIONS) {
+ printf("\n eval: recursion limit reached.\n");
+ return (EXECUTION_FAILURE);
+ }
+ recursion_count++;
+
if (no_options (list))
return (EX_USAGE);
list = loptend; /* skip over possible `--' */
--
1.8.4
taking into account the way eval is (ab)used it is probably a good
choice to have some recursion protection.
now: where to set recursion_count to 0?
cheers,
pg
On Thu, Oct 10, 2013 at 5:44 PM, Piotr Grzybowski wrote:
> helo all!
>
> I agree, it is abit off a bug. That should fix it (coding and writting from
> my mobile, so sorry for bad style ;-)) :
>
> cheers,
> pg
>
> ---
> builtins/alias.def | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/builtins/alias.def b/builtins/alias.def
> index d760ceb..7a7b510 100644
> --- a/builtins/alias.def
> +++ b/builtins/alias.def
> @@ -67,6 +67,9 @@ static void print_alias __P((alias_t *, int));
>
> extern int posixly_correct;
>
> +#define MAX_RECURSIONS 255
> +static int recursion_count=0;
> +
> /* Hack the alias command in a Korn shell way. */
> int
> alias_builtin (list)
> @@ -76,6 +79,10 @@ alias_builtin (list)
>alias_t **alias_list, *t;
>char *name, *value;
>
> + if (recursion_count>MAX_RECURSIONS) {
> + return EXECUTION_FAILURE;
> + }
> + recursion_count++;
>dflags = posixly_correct ? 0 : AL_REUSABLE;
>pflag = 0;
>reset_internal_getopt ();
> --
> 1.8.4
>
>
> On Oct 10, 2013 11:50 AM, "Oliver J. Morais"
> wrote:
>>
>> [Thu, Oct 10, 2013 at 11:38:47AM +0200] Andreas Schwab
>> > "Oliver J. Morais" writes:
>> > > Playing around with aliases, I stumbled over the following:
>> > > $ alias alias="eval alias"
>> > > $ alias foo=bar
>> > You have created an infinite recursion, same as f() { f; }; f.
>>
>> Sure, but I think bash should not just crash, zsh for example catches
>> this glitch:
>>
>> % alias alias="eval alias"
>> % alias foo=bar
>> zsh: job table full or recursion limit exceeded
>>
>> I know, bash != zsh and the eval-alias-foo is a silly thing to do,
>> but crashing is a bug :)
>>
Re: Reproducible SIGSEGV in bash 4.2 caused by alias.
On 10/10/2013 03:40 PM, Piotr Grzybowski wrote: > a small correction, if I may; while that was all very sweet, there > are two issues here: > > 1. recursion_count has to be reset somewhere, or else it is a global > alias limit :) > 2. a better place for this limit is acctually eval (probably leaving > alias recursion limit, before Oliver starts playing with it, is also a > good idea?): Why impose an arbitrary recursion limit at all? One of the GNU coding philosophies is to avoid arbitrary limits, and instead let you use the full power of your machine (ie. recurse to the full stack depth, rather than a hard-coded limit, where depending on available memory and ulimit settings, different users will want different limits). One way to do this is to link to the GNU libsigsegv library, which can be used to give a graceful error message rather than a core dump upon stack overflow (although gracefully recovering from overflow is a MUCH harder task, unless you can prove that overflow will never happen in the middle of a function such as malloc). -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: set -e is not clearly documented
On Monday, October 07, 2013 10:21:06 AM Chet Ramey wrote:
> The subshell command is clearly part of the || compound command. The
> subshell `knows' that it is part of || and set -e has no effect. This
> example has been discussed before, on this list and the austin-group
> Posix list, and the bash behavior is correct.
>
> Chet
Have you considered that adding proper exception handling might not be a large
step? Bash just needs to expose fine-grained error information and provide a
trigger for user-defined code to interpret it.
function missingFile { echo 'Tried opening some non-existing file!'
>&2; }
function badCmd { echo 'Unknown command.' >&2; }
function otherErr { printf 'Some unknown error was hit with code: %s\n'
"$1" >&2; }
typeset -A handlerMap=(
[file_not_found]=missingFile
[command_not_found]=badCmd
# User maps any conditions Bash knows how to throw as needed.
)
# If not ERR, an enhanced variant triggered on any update to
BASH_ERR
# Can be used in a manner similar to the Ksh KEYBD trap.
trap '"${handlerMap[$BASH_ERR]:-otherErr "$BASH_ERR"}"' ERR
# Bash sets BASH_ERR to "file_not_found" and triggers ERR.
User-defined
# code does the rest.
exec
Re: Reproducible SIGSEGV in bash 4.2 caused by alias.
On Thursday, October 10, 2013 11:40:31 PM Piotr Grzybowski wrote:
> 2. a better place for this limit is acctually eval (probably leaving
> alias recursion limit, before Oliver starts playing with it, is also a
> good idea?):
>
Objection! That would break my important aliases.
$ alias exit='eval "$BASH_COMMAND"'
$ alias shutdown='eval $BASH_COMMAND\&{,}'
--
Dan Douglas
Re: Reproducible SIGSEGV in bash 4.2 caused by alias.
On 11 Oct 2013, at 05:55, Dan Douglas wrote:
> Objection! That would break my important aliases.
>
> $ alias exit='eval "$BASH_COMMAND"'
> $ alias shutdown='eval $BASH_COMMAND\&{,}'
I have to start using those.
I am sorry here I thought that the idea was to not allow infinite calls, I can
send a patch with --dan option to alias which will not only allow arbitrary
recursion level, but also install those two automatically. I can drop in a
couple of aliases with rm ;-)
sincerely,
pg
Re: Reproducible SIGSEGV in bash 4.2 caused by alias.
On 11 Oct 2013, at 00:22, Eric Blake wrote: > > Why impose an arbitrary recursion limit at all? [..] > One way to do this is to link to the GNU libsigsegv library [..] > (although gracefully recovering from overflow is a MUCH harder task [..]). I personally do not mind linking with libsigsegv, if you can ensure that it will be present on all platforms bash runs, and if you provide some other mean to avoid going into infinite recursion (like #ifndef HAVE_LIB_SIGSEGV /*use hardcoded recursion limit*/ #endif) in case you do not have the lib. If you prefer, I can, according to the gnu philosophers (as you say), add a limit that will equal with the amount of function frames that can fit available memory :) to let you use the full power and explore the mysteries of infinite recursions :) Anyway, the patch was just a thought; I think that it is a good practice to avoid this kind of situations, especially when you are implementing a command that can define other commands, including itself, i.e., can be recursive in itself. cheers, pg
Bash 4.3 no longer handles traps when reading input with read
Good day, It seems like starting 4.3 (beta2) bash already delays handling traps until read exits. Is this intended? It would be a problem if read has a long timeout or doesn't have a timeout at all:
Re: Bash 4.3 no longer handles traps when reading input with read
Sorry I accidentally sent the message immediately. I use this script:
catcher() {
echo caught.
}
set -o monitor
trap catcher SIGCHLD
for (( ;; )); do
echo sleeping.
sleep 2s &
echo reading.
read -t 5
echo --
echo waiting.
wait
done
And the trap is always called every after 5 seconds when input already
times out:
sleeping.
reading.
caught.
--
waiting.
sleeping.
reading.
caught.
--
waiting.
sleeping.
reading.
...
Cheers, konsolebox
On Fri, Oct 11, 2013 at 2:47 PM, konsolebox wrote:
> Good day,
>
> It seems like starting 4.3 (beta2) bash already delays handling traps
> until read exits. Is this intended? It would be a problem if read has a
> long timeout or doesn't have a timeout at all:
>
>
>
