From: Oleg Nesterov <oleg@redhat.com>
To: Kees Cook <keescook@chromium.org>
Cc: Rik van Riel <riel@redhat.com>, Michal Hocko <mhocko@suse.com>,
Stanislav Kozina <skozina@redhat.com>,
linux-kernel@vger.kernel.org
Subject: get_arg_page() && ptr_size accounting
Date: Mon, 10 Sep 2018 14:29:07 +0200 [thread overview]
Message-ID: <20180910122907.GA23963@redhat.com> (raw)
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...
So get_arg_page() does
/*
* Since the stack will hold pointers to the strings, we
* must account for them as well.
*
* The size calculation is the entire vma while each arg page is
* built, so each time we get here it's calculating how far it
* is currently (rather than each call being just the newly
* added size from the arg page). As a result, we need to
* always add the entire size of the pointers, so that on the
* last call to get_arg_page() we'll actually have the entire
* correct size.
*/
ptr_size = (bprm->argc + bprm->envc) * sizeof(void *);
if (ptr_size > ULONG_MAX - size)
goto fail;
size += ptr_size;
OK, but
acct_arg_size(bprm, size / PAGE_SIZE);
after that doesn't look exactly right. This additional space will be used later
when the process already uses bprm->mm, right? so it shouldn't be accounted by
acct_arg_size().
Not to mention that ptr_size/PAGE_SIZE doesn't look right in any case...
In short. Am I totally confused or the patch below makes sense? This way we do
not need the fat comment.
Oleg.
--- x/fs/exec.c
+++ x/fs/exec.c
@@ -222,25 +222,17 @@ static struct page *get_arg_page(struct
unsigned long size = bprm->vma->vm_end - bprm->vma->vm_start;
unsigned long ptr_size, limit;
+ acct_arg_size(bprm, size / PAGE_SIZE);
+
/*
* Since the stack will hold pointers to the strings, we
* must account for them as well.
- *
- * The size calculation is the entire vma while each arg page is
- * built, so each time we get here it's calculating how far it
- * is currently (rather than each call being just the newly
- * added size from the arg page). As a result, we need to
- * always add the entire size of the pointers, so that on the
- * last call to get_arg_page() we'll actually have the entire
- * correct size.
*/
ptr_size = (bprm->argc + bprm->envc) * sizeof(void *);
if (ptr_size > ULONG_MAX - size)
goto fail;
size += ptr_size;
- acct_arg_size(bprm, size / PAGE_SIZE);
-
/*
* We've historically supported up to 32 pages (ARG_MAX)
* of argument strings even with small stacks
next reply other threads:[~2018-09-10 12:29 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-10 12:29 Oleg Nesterov [this message]
2018-09-10 16:41 ` get_arg_page() && ptr_size accounting Kees Cook
2018-09-10 16:45 ` Kees Cook
2018-09-10 17:21 ` Oleg Nesterov
2018-09-10 17:43 ` Oleg Nesterov
2018-09-11 4:30 ` Kees Cook
2018-09-11 15:29 ` Oleg Nesterov
2018-09-11 4:27 ` Kees Cook
2018-09-11 15:25 ` Oleg Nesterov
2018-09-10 17:18 ` Oleg Nesterov
2018-09-11 4:23 ` Kees Cook
2018-09-11 14:13 ` Oleg Nesterov
2018-09-11 19:06 ` Kees Cook
2018-09-12 12:27 ` Oleg Nesterov
2018-09-12 14:23 ` Oleg Nesterov
2018-09-12 20:42 ` Kees Cook
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180910122907.GA23963@redhat.com \
--to=oleg@redhat.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mhocko@suse.com \
--cc=riel@redhat.com \
--cc=skozina@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.