[EVAL] Fix use-after-free in dotrap/evalstring
While going through trap code it occured to me that we have a use-after-free bug. commit 6c3f73bc536082fec38bd36e6c8a121033c68835 Author: Herbert Xu herb...@gondor.apana.org.au Date: Thu Oct 2 08:26:06 2014 +0800 [EVAL] Fix use-after-free in dotrap/evalstring The function dotrap calls evalstring using the stored trap string. If evalstring then unsets that exact trap string then we will end up using freed memory. This patch fixes it by making evalstring always duplicate the string before using it. Signed-off-by: Herbert Xu herb...@gondor.apana.org.au diff --git a/ChangeLog b/ChangeLog index f161a13..a56fc5e 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,7 @@ +2014-10-02 Herbert Xu herb...@gondor.apana.org.au + + * Fix use-after-free in dotrap/evalstring. + 2014-09-29 Herbert Xu herb...@gondor.apana.org.au * Kill pgetc_macro. diff --git a/src/eval.c b/src/eval.c index c7358a6..3cfa1e5 100644 --- a/src/eval.c +++ b/src/eval.c @@ -160,6 +160,7 @@ evalstring(char *s, int flags) struct stackmark smark; int status; + s = sstrdup(s); setinputstring(s); setstackmark(smark); @@ -171,7 +172,9 @@ evalstring(char *s, int flags) if (evalskip) break; } + popstackmark(smark); popfile(); + stunalloc(s); return status; } diff --git a/src/histedit.c b/src/histedit.c index b27d629..94465d7 100644 --- a/src/histedit.c +++ b/src/histedit.c @@ -372,8 +372,7 @@ histcmd(int argc, char **argv) out2str(s); } - evalstring(strcpy(stalloc(strlen(s) + 1), s), - 0); + evalstring(s, 0); if (displayhist hist) { /* * XXX what about recursive and Cheers, -- Email: Herbert Xu herb...@gondor.apana.org.au Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line unsubscribe dash in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Support DOS paths in dash
Eric Blake ebl...@redhat.com wrote: I'm not interested in burdening the cygwin build of dash with a one-off patch, so I'd like to gauge the upstream thoughts - is it worth including platform-specific patches like this (no penalty to build size of non-cygwin platforms, and on cygwin, it allows 'cd c:/' to behave as shorthand for 'cd /cygdrive/c/')? If the patch lands in dash.git, then I'll rebuild the cygwin port of dash to include a backport (rather than waiting for 0.5.9 to be released). If there is no interest, I'd rather just drop the patch. The cygwin community already states that /cygdrive/c notation is the official way to access drive letters, and that if 'c:/' works it is nice, but it is not a design goal to always have it work. It's fine by me. Cheers, -- Email: Herbert Xu herb...@gondor.apana.org.au Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line unsubscribe dash in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Support DOS paths in dash
On Oct 1, 2014, at 8:41 PM, Herbert Xu herb...@gondor.apana.org.au wrote: Eric Blake ebl...@redhat.com wrote: I'm not interested in burdening the cygwin build of dash with a one-off patch, so I'd like to gauge the upstream thoughts - is it worth including platform-specific patches like this (no penalty to build size of non-cygwin platforms, and on cygwin, it allows 'cd c:/' to behave as shorthand for 'cd /cygdrive/c/')? If the patch lands in dash.git, then I'll rebuild the cygwin port of dash to include a backport (rather than waiting for 0.5.9 to be released). If there is no interest, I'd rather just drop the patch. The cygwin community already states that /cygdrive/c notation is the official way to access drive letters, and that if 'c:/' works it is nice, but it is not a design goal to always have it work. It's fine by me. Is that a yes to allow platform-specific patches into dash? Thanks, -Edward -- To unsubscribe from this list: send the line unsubscribe dash in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html