Messages in this thread Patch in this message | | | Date | Mon, 10 Sep 2018 19:43:55 +0200 | From | Oleg Nesterov <> | Subject | Re: get_arg_page() && ptr_size accounting |
| |
On 09/10, Oleg Nesterov wrote: > > On 09/10, Kees Cook wrote: > > > > On Mon, Sep 10, 2018 at 9:41 AM, Kees Cook <keescook@chromium.org> wrote: > > > On Mon, Sep 10, 2018 at 5:29 AM, Oleg Nesterov <oleg@redhat.com> wrote: > > >> Hi Kees, > > >> > > >> I was thinking about backporting the commit 98da7d08850fb8bde > > >> ("fs/exec.c: account for argv/envp pointers"), but I am not sure > > >> I understand it... > > > > BTW, if you backport that, please get the rest associated with the > > various Stack Clash related weaknesses: > > may be... > > > da029c11e6b1 exec: Limit arg stack to at most 75% of _STK_LIM > > and I have to admit that I do not understand this patch at all, the > changelog explains nothing. > > Could you explain what this patch actually prevents from? Especially > now that we have stack_guard_gap?
forgot to mention...
with this patch
#define MAX_ARG_STRINGS 0x7FFFFFFF
doesn't match the reality. perhaps something like below makes sense just to make it clear, but this is cosmetic.
Oleg.
--- x/fs/exec.c +++ x/fs/exec.c @@ -1789,11 +1789,13 @@ static int __do_execve_file(int fd, stru if (retval) goto out_unmark; - bprm->argc = count(argv, MAX_ARG_STRINGS); + int max_arg_strings = _STK_LIM / 4 * 3 / 2; // actually even less than + + bprm->argc = count(argv, max_arg_strings); if ((retval = bprm->argc) < 0) goto out; - bprm->envc = count(envp, MAX_ARG_STRINGS); + bprm->envc = count(envp, max_arg_strings - bprm->argc); if ((retval = bprm->envc) < 0) goto out;
| |