On Thu, 2007-06-14 at 13:58 -0700, Ollie Wild wrote: > > @@ -1385,6 +1401,10 @@ int do_execve(char * filename, > > goto out; > > bprm->argv_len = env_p - bprm->p; > > > > + retval = expand_arg_vma(bprm); > > + if (retval < 0) > > + goto out; > > + > > retval = search_binary_handler(bprm,regs); > > if (retval >= 0) { > > /* execve success */ > > At this point bprm->argc hasn't been finalized yet. For example, the > script binfmt reads the script header and adds additional arguments. > The flush_old_exec() function is a better place to call this.
Sure, but at this time most of it is there, so when there are many, this allocates the most of it. > I'm not 100% sure this is the right way to handle this, though. The > problem isn't as simple as ensuring the stack doesn't overflow during > argument allocation. We also need to ensure the program has > sufficient stack space to run subsequently. Otherwise, the observable > behavior is identical. Well, not identical, but similar indeed. > Since we can't realistically predict > acceptable stack availability requirements, some amount of uncertainty > is always going to exist. > A good heuristic, though, might be to limit > argument size to a percentage (say 25%) of maximum stack size and > validate this inside copy_strings(). Right, this seems a much simpler approach. I like it. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/