linux-kernel - Re: [patch 0/3] no MAX_ARG

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 14 Jun 2007 23:18:00 +0200
From:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
To:	Ollie Wild <aaw@...gle.com>
Cc:	"Luck, Tony" <tony.luck@...el.com>, linux-kernel@...r.kernel.org,
	parisc-linux@...ts.parisc-linux.org, linux-mm@...ck.org,
	linux-arch@...r.kernel.org, Andrew Morton <akpm@...l.org>,
	Ingo Molnar <mingo@...e.hu>, Andi Kleen <ak@...e.de>
Subject: Re: [patch 0/3] no MAX_ARG_PAGES -v2

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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/