* posix_spawnp stack overflow/corruption by child when PATH is large?
@ 2017-09-14 20:39 Will Dietz
2017-09-15 14:17 ` Rich Felker
0 siblings, 1 reply; 6+ messages in thread
From: Will Dietz @ 2017-09-14 20:39 UTC (permalink / raw)
To: musl
Hi,
I believe there is a bug in posix_spawn/execvpe, please take a look and confirm
or kindly let me know if I'm mistaken and accept my apologies :).
It looks like __posix_spawnx calls clone() with a 1024-byte stack buffer
(allocated from its own stack), which is insufficient to handle stack
allocations performed
in execvpe which are something around a few bytes more than NAME_MAX+PATH_MAX.
This path is taken when using posix_spawnp, and the problem exists on
1.1.16 and latest git.
For what it's worth I tracked this down from a crash in 'bison' when
invoking m4,
but I've had success reproducing it with the following demo program
and driver script:
-------------------------------------------
#include <spawn.h>
#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <sys/wait.h>
extern char **environ;
int main() {
pid_t p;
char *argv[] = {"sh", "-c", "echo Hello", NULL};
int s, status;
s = posix_spawnp(&p, "sh", NULL, NULL, argv, environ);
if (s) {
perror("posix_spawn");
exit(1);
}
s = waitpid(p, &status, 0);
printf("pid: %d, s: %d, status: %d\n", p, s, status);
return 0;
}
--------------
And little shell script to create a suitably large PATH (mostly to
demonstrate what I mean, not for unmodified use):
---------------
#!/bin/sh
SLASH_100_As="/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
SUFFIX="/123456789012345678901234567" #1234567890" #1234567890"
VAR="/bin:$SUFFIX"
for x in `seq 10`; do
VAR="${SLASH_100_As}:$VAR"
done
echo $VAR
echo $VAR|wc -c
# Works fine with normal PATH
~/cur/musl-spawn/test
~/cur/musl-spawn/test
# Crashes when PATH is ~1050 characters
PATH=$VAR \
~/cur/musl-spawn/test
--------------
Where "~/cur/musl-spawn/test" is the test program compiled against musl.
I cannot speak regarding any security implications, but since this may
grant some measure of stack-scribbling-powers it seems to warrant
being given brief attention in this context.
An easy fix is to bump the size of the 'char stack[1024]' in
src/process/posix_spawn.c to a suitable value-- 8096 is overkill but
does the trick, for example.
Please let me know if I'm missing something or if details are not clear.
Thanks!
~Will
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: posix_spawnp stack overflow/corruption by child when PATH is large? 2017-09-14 20:39 posix_spawnp stack overflow/corruption by child when PATH is large? Will Dietz @ 2017-09-15 14:17 ` Rich Felker 2017-09-18 19:31 ` Will Dietz 0 siblings, 1 reply; 6+ messages in thread From: Rich Felker @ 2017-09-15 14:17 UTC (permalink / raw) To: musl On Thu, Sep 14, 2017 at 03:39:35PM -0500, Will Dietz wrote: > Hi, > > I believe there is a bug in posix_spawn/execvpe, please take a look and confirm > or kindly let me know if I'm mistaken and accept my apologies :). > > It looks like __posix_spawnx calls clone() with a 1024-byte stack buffer > (allocated from its own stack), which is insufficient to handle stack > allocations performed > in execvpe which are something around a few bytes more than NAME_MAX+PATH_MAX. > > This path is taken when using posix_spawnp, and the problem exists on > 1.1.16 and latest git. > > For what it's worth I tracked this down from a crash in 'bison' when > invoking m4, > but I've had success reproducing it with the following demo program > and driver script: > > ------------------------------------------- > #include <spawn.h> > #include <stdio.h> > #include <stdlib.h> > #include <sys/types.h> > #include <sys/wait.h> > > extern char **environ; > > int main() { > > pid_t p; > char *argv[] = {"sh", "-c", "echo Hello", NULL}; > int s, status; > s = posix_spawnp(&p, "sh", NULL, NULL, argv, environ); > if (s) { > perror("posix_spawn"); > exit(1); > } > > s = waitpid(p, &status, 0); > > printf("pid: %d, s: %d, status: %d\n", p, s, status); > > return 0; > } > -------------- > > And little shell script to create a suitably large PATH (mostly to > demonstrate what I mean, not for unmodified use): > --------------- > #!/bin/sh > > SLASH_100_As="/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" > SUFFIX="/123456789012345678901234567" #1234567890" #1234567890" > > VAR="/bin:$SUFFIX" > for x in `seq 10`; do > VAR="${SLASH_100_As}:$VAR" > done > > echo $VAR > echo $VAR|wc -c > > # Works fine with normal PATH > ~/cur/musl-spawn/test > ~/cur/musl-spawn/test > > # Crashes when PATH is ~1050 characters > PATH=$VAR \ > ~/cur/musl-spawn/test > -------------- > > Where "~/cur/musl-spawn/test" is the test program compiled against musl. > > I cannot speak regarding any security implications, but since this may > grant some measure of stack-scribbling-powers it seems to warrant > being given brief attention in this context. > > An easy fix is to bump the size of the 'char stack[1024]' in > src/process/posix_spawn.c to a suitable value-- 8096 is overkill but > does the trick, for example. > > Please let me know if I'm missing something or if details are not clear. It's very clear, and this seems pretty serious. 1024+PATH_MAX would probably be a safe limit. If we care about minimal stack usage when plain posix_spawn (not spawnp) is called, it could be something like "exec==execve ? 1024 : 1024+PATH_MAX", perhaps. Rich ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: posix_spawnp stack overflow/corruption by child when PATH is large? 2017-09-15 14:17 ` Rich Felker @ 2017-09-18 19:31 ` Will Dietz 2017-10-19 21:05 ` Will Dietz 0 siblings, 1 reply; 6+ messages in thread From: Will Dietz @ 2017-09-18 19:31 UTC (permalink / raw) To: musl [-- Attachment #1: Type: text/plain, Size: 3342 bytes --] Thanks for taking a look and for the confirmation! I agree that 1024+PATH_MAX would be a reasonable value here, good call. I had similar thought about making the extra stack usage conditional, but would rather keep it simple and clear-- as weighed against my possibly wrong "expectation" that the difference won't be significant for folks. I don't feel strongly about it and of course defer to your judgement :). Patch making the discussed change is attached. ~Will On Fri, Sep 15, 2017 at 9:17 AM, Rich Felker <dalias@libc.org> wrote: > On Thu, Sep 14, 2017 at 03:39:35PM -0500, Will Dietz wrote: >> Hi, >> >> I believe there is a bug in posix_spawn/execvpe, please take a look and confirm >> or kindly let me know if I'm mistaken and accept my apologies :). >> >> It looks like __posix_spawnx calls clone() with a 1024-byte stack buffer >> (allocated from its own stack), which is insufficient to handle stack >> allocations performed >> in execvpe which are something around a few bytes more than NAME_MAX+PATH_MAX. >> >> This path is taken when using posix_spawnp, and the problem exists on >> 1.1.16 and latest git. >> >> For what it's worth I tracked this down from a crash in 'bison' when >> invoking m4, >> but I've had success reproducing it with the following demo program >> and driver script: >> >> ------------------------------------------- >> #include <spawn.h> >> #include <stdio.h> >> #include <stdlib.h> >> #include <sys/types.h> >> #include <sys/wait.h> >> >> extern char **environ; >> >> int main() { >> >> pid_t p; >> char *argv[] = {"sh", "-c", "echo Hello", NULL}; >> int s, status; >> s = posix_spawnp(&p, "sh", NULL, NULL, argv, environ); >> if (s) { >> perror("posix_spawn"); >> exit(1); >> } >> >> s = waitpid(p, &status, 0); >> >> printf("pid: %d, s: %d, status: %d\n", p, s, status); >> >> return 0; >> } >> -------------- >> >> And little shell script to create a suitably large PATH (mostly to >> demonstrate what I mean, not for unmodified use): >> --------------- >> #!/bin/sh >> >> SLASH_100_As="/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" >> SUFFIX="/123456789012345678901234567" #1234567890" #1234567890" >> >> VAR="/bin:$SUFFIX" >> for x in `seq 10`; do >> VAR="${SLASH_100_As}:$VAR" >> done >> >> echo $VAR >> echo $VAR|wc -c >> >> # Works fine with normal PATH >> ~/cur/musl-spawn/test >> ~/cur/musl-spawn/test >> >> # Crashes when PATH is ~1050 characters >> PATH=$VAR \ >> ~/cur/musl-spawn/test >> -------------- >> >> Where "~/cur/musl-spawn/test" is the test program compiled against musl. >> >> I cannot speak regarding any security implications, but since this may >> grant some measure of stack-scribbling-powers it seems to warrant >> being given brief attention in this context. >> >> An easy fix is to bump the size of the 'char stack[1024]' in >> src/process/posix_spawn.c to a suitable value-- 8096 is overkill but >> does the trick, for example. >> >> Please let me know if I'm missing something or if details are not clear. > > It's very clear, and this seems pretty serious. 1024+PATH_MAX would > probably be a safe limit. If we care about minimal stack usage when > plain posix_spawn (not spawnp) is called, it could be something like > "exec==execve ? 1024 : 1024+PATH_MAX", perhaps. > > Rich [-- Attachment #2: 0001-posix_spawn-use-larger-stack-to-cover-worst-case-in-.patch --] [-- Type: text/x-patch, Size: 1058 bytes --] From 9b5ca541b2c97850b00a051ad21efc46792b91b2 Mon Sep 17 00:00:00 2001 From: Will Dietz <w@wdtz.org> Date: Thu, 14 Sep 2017 16:32:59 -0500 Subject: [PATCH] posix_spawn: use larger stack to cover worst-case in execvpe execvpe stack-allocates a buffer used to hold the full path (combination of a PATH entry and the program name) while searching through $PATH, so at least NAME_MAX+PATH_MAX is needed. The stack size can be made conditionally smaller (the current 1024 appears appropriate) should this larger size be burdensome in those situations. --- src/process/posix_spawn.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/process/posix_spawn.c b/src/process/posix_spawn.c index ea5d2998..0849c71f 100644 --- a/src/process/posix_spawn.c +++ b/src/process/posix_spawn.c @@ -152,7 +152,7 @@ int __posix_spawnx(pid_t *restrict res, const char *restrict path, char *const argv[restrict], char *const envp[restrict]) { pid_t pid; - char stack[1024]; + char stack[1024+PATH_MAX]; int ec=0, cs; struct args args; -- 2.14.1 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: posix_spawnp stack overflow/corruption by child when PATH is large? 2017-09-18 19:31 ` Will Dietz @ 2017-10-19 21:05 ` Will Dietz 2017-10-19 21:10 ` Rich Felker 0 siblings, 1 reply; 6+ messages in thread From: Will Dietz @ 2017-10-19 21:05 UTC (permalink / raw) To: musl (soft ping) ~Will On Mon, Sep 18, 2017 at 2:31 PM, Will Dietz <w@wdtz.org> wrote: > Thanks for taking a look and for the confirmation! > > I agree that 1024+PATH_MAX would be a reasonable value here, good call. > > I had similar thought about making the extra stack usage conditional, > but would rather keep it simple and clear-- as weighed against my possibly > wrong "expectation" that the difference won't be significant for folks. > I don't feel strongly about it and of course defer to your judgement :). > > Patch making the discussed change is attached. > > ~Will > > > On Fri, Sep 15, 2017 at 9:17 AM, Rich Felker <dalias@libc.org> wrote: >> On Thu, Sep 14, 2017 at 03:39:35PM -0500, Will Dietz wrote: >>> Hi, >>> >>> I believe there is a bug in posix_spawn/execvpe, please take a look and confirm >>> or kindly let me know if I'm mistaken and accept my apologies :). >>> >>> It looks like __posix_spawnx calls clone() with a 1024-byte stack buffer >>> (allocated from its own stack), which is insufficient to handle stack >>> allocations performed >>> in execvpe which are something around a few bytes more than NAME_MAX+PATH_MAX. >>> >>> This path is taken when using posix_spawnp, and the problem exists on >>> 1.1.16 and latest git. >>> >>> For what it's worth I tracked this down from a crash in 'bison' when >>> invoking m4, >>> but I've had success reproducing it with the following demo program >>> and driver script: >>> >>> ------------------------------------------- >>> #include <spawn.h> >>> #include <stdio.h> >>> #include <stdlib.h> >>> #include <sys/types.h> >>> #include <sys/wait.h> >>> >>> extern char **environ; >>> >>> int main() { >>> >>> pid_t p; >>> char *argv[] = {"sh", "-c", "echo Hello", NULL}; >>> int s, status; >>> s = posix_spawnp(&p, "sh", NULL, NULL, argv, environ); >>> if (s) { >>> perror("posix_spawn"); >>> exit(1); >>> } >>> >>> s = waitpid(p, &status, 0); >>> >>> printf("pid: %d, s: %d, status: %d\n", p, s, status); >>> >>> return 0; >>> } >>> -------------- >>> >>> And little shell script to create a suitably large PATH (mostly to >>> demonstrate what I mean, not for unmodified use): >>> --------------- >>> #!/bin/sh >>> >>> SLASH_100_As="/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" >>> SUFFIX="/123456789012345678901234567" #1234567890" #1234567890" >>> >>> VAR="/bin:$SUFFIX" >>> for x in `seq 10`; do >>> VAR="${SLASH_100_As}:$VAR" >>> done >>> >>> echo $VAR >>> echo $VAR|wc -c >>> >>> # Works fine with normal PATH >>> ~/cur/musl-spawn/test >>> ~/cur/musl-spawn/test >>> >>> # Crashes when PATH is ~1050 characters >>> PATH=$VAR \ >>> ~/cur/musl-spawn/test >>> -------------- >>> >>> Where "~/cur/musl-spawn/test" is the test program compiled against musl. >>> >>> I cannot speak regarding any security implications, but since this may >>> grant some measure of stack-scribbling-powers it seems to warrant >>> being given brief attention in this context. >>> >>> An easy fix is to bump the size of the 'char stack[1024]' in >>> src/process/posix_spawn.c to a suitable value-- 8096 is overkill but >>> does the trick, for example. >>> >>> Please let me know if I'm missing something or if details are not clear. >> >> It's very clear, and this seems pretty serious. 1024+PATH_MAX would >> probably be a safe limit. If we care about minimal stack usage when >> plain posix_spawn (not spawnp) is called, it could be something like >> "exec==execve ? 1024 : 1024+PATH_MAX", perhaps. >> >> Rich ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: posix_spawnp stack overflow/corruption by child when PATH is large? 2017-10-19 21:05 ` Will Dietz @ 2017-10-19 21:10 ` Rich Felker 2017-10-21 15:54 ` Will Dietz 0 siblings, 1 reply; 6+ messages in thread From: Rich Felker @ 2017-10-19 21:10 UTC (permalink / raw) To: musl On Thu, Oct 19, 2017 at 04:05:19PM -0500, Will Dietz wrote: > (soft ping) Oops, I probably should have gotten this into the release. At least it makes a good motivation to pick up the release pace and make another release soon. Rich > On Mon, Sep 18, 2017 at 2:31 PM, Will Dietz <w@wdtz.org> wrote: > > Thanks for taking a look and for the confirmation! > > > > I agree that 1024+PATH_MAX would be a reasonable value here, good call. > > > > I had similar thought about making the extra stack usage conditional, > > but would rather keep it simple and clear-- as weighed against my possibly > > wrong "expectation" that the difference won't be significant for folks. > > I don't feel strongly about it and of course defer to your judgement :). > > > > Patch making the discussed change is attached. > > > > ~Will > > > > > > On Fri, Sep 15, 2017 at 9:17 AM, Rich Felker <dalias@libc.org> wrote: > >> On Thu, Sep 14, 2017 at 03:39:35PM -0500, Will Dietz wrote: > >>> Hi, > >>> > >>> I believe there is a bug in posix_spawn/execvpe, please take a look and confirm > >>> or kindly let me know if I'm mistaken and accept my apologies :). > >>> > >>> It looks like __posix_spawnx calls clone() with a 1024-byte stack buffer > >>> (allocated from its own stack), which is insufficient to handle stack > >>> allocations performed > >>> in execvpe which are something around a few bytes more than NAME_MAX+PATH_MAX. > >>> > >>> This path is taken when using posix_spawnp, and the problem exists on > >>> 1.1.16 and latest git. > >>> > >>> For what it's worth I tracked this down from a crash in 'bison' when > >>> invoking m4, > >>> but I've had success reproducing it with the following demo program > >>> and driver script: > >>> > >>> ------------------------------------------- > >>> #include <spawn.h> > >>> #include <stdio.h> > >>> #include <stdlib.h> > >>> #include <sys/types.h> > >>> #include <sys/wait.h> > >>> > >>> extern char **environ; > >>> > >>> int main() { > >>> > >>> pid_t p; > >>> char *argv[] = {"sh", "-c", "echo Hello", NULL}; > >>> int s, status; > >>> s = posix_spawnp(&p, "sh", NULL, NULL, argv, environ); > >>> if (s) { > >>> perror("posix_spawn"); > >>> exit(1); > >>> } > >>> > >>> s = waitpid(p, &status, 0); > >>> > >>> printf("pid: %d, s: %d, status: %d\n", p, s, status); > >>> > >>> return 0; > >>> } > >>> -------------- > >>> > >>> And little shell script to create a suitably large PATH (mostly to > >>> demonstrate what I mean, not for unmodified use): > >>> --------------- > >>> #!/bin/sh > >>> > >>> SLASH_100_As="/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" > >>> SUFFIX="/123456789012345678901234567" #1234567890" #1234567890" > >>> > >>> VAR="/bin:$SUFFIX" > >>> for x in `seq 10`; do > >>> VAR="${SLASH_100_As}:$VAR" > >>> done > >>> > >>> echo $VAR > >>> echo $VAR|wc -c > >>> > >>> # Works fine with normal PATH > >>> ~/cur/musl-spawn/test > >>> ~/cur/musl-spawn/test > >>> > >>> # Crashes when PATH is ~1050 characters > >>> PATH=$VAR \ > >>> ~/cur/musl-spawn/test > >>> -------------- > >>> > >>> Where "~/cur/musl-spawn/test" is the test program compiled against musl. > >>> > >>> I cannot speak regarding any security implications, but since this may > >>> grant some measure of stack-scribbling-powers it seems to warrant > >>> being given brief attention in this context. > >>> > >>> An easy fix is to bump the size of the 'char stack[1024]' in > >>> src/process/posix_spawn.c to a suitable value-- 8096 is overkill but > >>> does the trick, for example. > >>> > >>> Please let me know if I'm missing something or if details are not clear. > >> > >> It's very clear, and this seems pretty serious. 1024+PATH_MAX would > >> probably be a safe limit. If we care about minimal stack usage when > >> plain posix_spawn (not spawnp) is called, it could be something like > >> "exec==execve ? 1024 : 1024+PATH_MAX", perhaps. > >> > >> Rich ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: posix_spawnp stack overflow/corruption by child when PATH is large? 2017-10-19 21:10 ` Rich Felker @ 2017-10-21 15:54 ` Will Dietz 0 siblings, 0 replies; 6+ messages in thread From: Will Dietz @ 2017-10-21 15:54 UTC (permalink / raw) To: musl Sounds like a plan! Don't mean to bug, just want to make sure it's not lost in the bustle of the release :). ~Will On Thu, Oct 19, 2017 at 4:10 PM, Rich Felker <dalias@libc.org> wrote: > On Thu, Oct 19, 2017 at 04:05:19PM -0500, Will Dietz wrote: >> (soft ping) > > Oops, I probably should have gotten this into the release. At least it > makes a good motivation to pick up the release pace and make another > release soon. > > Rich > > > >> On Mon, Sep 18, 2017 at 2:31 PM, Will Dietz <w@wdtz.org> wrote: >> > Thanks for taking a look and for the confirmation! >> > >> > I agree that 1024+PATH_MAX would be a reasonable value here, good call. >> > >> > I had similar thought about making the extra stack usage conditional, >> > but would rather keep it simple and clear-- as weighed against my possibly >> > wrong "expectation" that the difference won't be significant for folks. >> > I don't feel strongly about it and of course defer to your judgement :). >> > >> > Patch making the discussed change is attached. >> > >> > ~Will >> > >> > >> > On Fri, Sep 15, 2017 at 9:17 AM, Rich Felker <dalias@libc.org> wrote: >> >> On Thu, Sep 14, 2017 at 03:39:35PM -0500, Will Dietz wrote: >> >>> Hi, >> >>> >> >>> I believe there is a bug in posix_spawn/execvpe, please take a look and confirm >> >>> or kindly let me know if I'm mistaken and accept my apologies :). >> >>> >> >>> It looks like __posix_spawnx calls clone() with a 1024-byte stack buffer >> >>> (allocated from its own stack), which is insufficient to handle stack >> >>> allocations performed >> >>> in execvpe which are something around a few bytes more than NAME_MAX+PATH_MAX. >> >>> >> >>> This path is taken when using posix_spawnp, and the problem exists on >> >>> 1.1.16 and latest git. >> >>> >> >>> For what it's worth I tracked this down from a crash in 'bison' when >> >>> invoking m4, >> >>> but I've had success reproducing it with the following demo program >> >>> and driver script: >> >>> >> >>> ------------------------------------------- >> >>> #include <spawn.h> >> >>> #include <stdio.h> >> >>> #include <stdlib.h> >> >>> #include <sys/types.h> >> >>> #include <sys/wait.h> >> >>> >> >>> extern char **environ; >> >>> >> >>> int main() { >> >>> >> >>> pid_t p; >> >>> char *argv[] = {"sh", "-c", "echo Hello", NULL}; >> >>> int s, status; >> >>> s = posix_spawnp(&p, "sh", NULL, NULL, argv, environ); >> >>> if (s) { >> >>> perror("posix_spawn"); >> >>> exit(1); >> >>> } >> >>> >> >>> s = waitpid(p, &status, 0); >> >>> >> >>> printf("pid: %d, s: %d, status: %d\n", p, s, status); >> >>> >> >>> return 0; >> >>> } >> >>> -------------- >> >>> >> >>> And little shell script to create a suitably large PATH (mostly to >> >>> demonstrate what I mean, not for unmodified use): >> >>> --------------- >> >>> #!/bin/sh >> >>> >> >>> SLASH_100_As="/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" >> >>> SUFFIX="/123456789012345678901234567" #1234567890" #1234567890" >> >>> >> >>> VAR="/bin:$SUFFIX" >> >>> for x in `seq 10`; do >> >>> VAR="${SLASH_100_As}:$VAR" >> >>> done >> >>> >> >>> echo $VAR >> >>> echo $VAR|wc -c >> >>> >> >>> # Works fine with normal PATH >> >>> ~/cur/musl-spawn/test >> >>> ~/cur/musl-spawn/test >> >>> >> >>> # Crashes when PATH is ~1050 characters >> >>> PATH=$VAR \ >> >>> ~/cur/musl-spawn/test >> >>> -------------- >> >>> >> >>> Where "~/cur/musl-spawn/test" is the test program compiled against musl. >> >>> >> >>> I cannot speak regarding any security implications, but since this may >> >>> grant some measure of stack-scribbling-powers it seems to warrant >> >>> being given brief attention in this context. >> >>> >> >>> An easy fix is to bump the size of the 'char stack[1024]' in >> >>> src/process/posix_spawn.c to a suitable value-- 8096 is overkill but >> >>> does the trick, for example. >> >>> >> >>> Please let me know if I'm missing something or if details are not clear. >> >> >> >> It's very clear, and this seems pretty serious. 1024+PATH_MAX would >> >> probably be a safe limit. If we care about minimal stack usage when >> >> plain posix_spawn (not spawnp) is called, it could be something like >> >> "exec==execve ? 1024 : 1024+PATH_MAX", perhaps. >> >> >> >> Rich ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2017-10-21 15:54 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-09-14 20:39 posix_spawnp stack overflow/corruption by child when PATH is large? Will Dietz 2017-09-15 14:17 ` Rich Felker 2017-09-18 19:31 ` Will Dietz 2017-10-19 21:05 ` Will Dietz 2017-10-19 21:10 ` Rich Felker 2017-10-21 15:54 ` Will Dietz
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/musl/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).