[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180910174355.GA27312@redhat.com>
Date: Mon, 10 Sep 2018 19:43:55 +0200
From: Oleg Nesterov <oleg@...hat.com>
To: Kees Cook <keescook@...omium.org>
Cc: Rik van Riel <riel@...hat.com>, Michal Hocko <mhocko@...e.com>,
Stanislav Kozina <skozina@...hat.com>,
LKML <linux-kernel@...r.kernel.org>
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@...omium.org> wrote:
> > > On Mon, Sep 10, 2018 at 5:29 AM, Oleg Nesterov <oleg@...hat.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;
Powered by blists - more mailing lists