From: Oleg Nesterov <oleg@redhat.com>
To: Kees Cook <keescook@chromium.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Zach Levis <zml@linux.vnet.ibm.com>,
Al Viro <viro@zeniv.linux.org.uk>,
Evgeniy Polyakov <zbr@ioremap.net>,
LKML <linux-kernel@vger.kernel.org>
Subject: [PATCH v2 2/3] exec: kill "int depth" in search_binary_handler()
Date: Sat, 3 Aug 2013 20:55:34 +0200 [thread overview]
Message-ID: <20130803185534.GA7452@redhat.com> (raw)
In-Reply-To: <CAGXu5j+=-n7S1VNyFR8oZ+bzh3iG8_cirUaNa48CGGh7DX805Q@mail.gmail.com>
On 08/03, Kees Cook wrote:
>
> On Thu, Aug 1, 2013 at 12:05 PM, Oleg Nesterov <oleg@redhat.com> wrote:
> > Nobody except search_binary_handler() should touch ->recursion_depth,
> > "int depth" buys nothing but complicates the code, kill it.
>
> I'd like to see a comment added to binfmts.h's recursion_depth field
> that reminds people that recursion_depth is for
> search_binary_handler()'s use only, and a binfmt loader shouldn't
> touch it.
And this comment probably makes sense even without this change
> Besides that, yeah, sensible clean up.
OK, thanks, please see v2. The only change is the comment in .h
------------------------------------------------------------------------------
Subject: [PATCH 1/1] exec: kill "int depth" in search_binary_handler()
Nobody except search_binary_handler() should touch ->recursion_depth,
"int depth" buys nothing but complicates the code, kill it.
Probably we should also kill "fn" and the !NULL check, ->load_binary
should be always defined. And it can not go away after read_unlock()
or this code is buggy anyway.
v2: add the comment about linux_binprm->recursion_depth
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
---
fs/exec.c | 9 ++++-----
include/linux/binfmts.h | 2 +-
2 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/fs/exec.c b/fs/exec.c
index a9ae4f2..f32079c 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -1370,12 +1370,11 @@ EXPORT_SYMBOL(remove_arg_zero);
*/
int search_binary_handler(struct linux_binprm *bprm)
{
- unsigned int depth = bprm->recursion_depth;
- int try,retval;
+ int try, retval;
struct linux_binfmt *fmt;
/* This allows 4 levels of binfmt rewrites before failing hard. */
- if (depth > 5)
+ if (bprm->recursion_depth > 5)
return -ELOOP;
retval = security_bprm_check(bprm);
@@ -1396,9 +1395,9 @@ int search_binary_handler(struct linux_binprm *bprm)
if (!try_module_get(fmt->module))
continue;
read_unlock(&binfmt_lock);
- bprm->recursion_depth = depth + 1;
+ bprm->recursion_depth++;
retval = fn(bprm);
- bprm->recursion_depth = depth;
+ bprm->recursion_depth--;
if (retval >= 0) {
put_binfmt(fmt);
allow_write_access(bprm->file);
diff --git a/include/linux/binfmts.h b/include/linux/binfmts.h
index 70cf138..e8112ae 100644
--- a/include/linux/binfmts.h
+++ b/include/linux/binfmts.h
@@ -31,7 +31,7 @@ struct linux_binprm {
#ifdef __alpha__
unsigned int taso:1;
#endif
- unsigned int recursion_depth;
+ unsigned int recursion_depth; /* only for search_binary_handler() */
struct file * file;
struct cred *cred; /* new credentials */
int unsafe; /* how unsafe this exec is (mask of LSM_UNSAFE_*) */
--
1.5.5.1
next prev parent reply other threads:[~2013-08-03 19:01 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-01 19:04 [PATCH 0/3] exec: minor cleanups + minor fix Oleg Nesterov
2013-08-01 19:05 ` [PATCH 1/3] exec: introduce exec_binprm() for "depth == 0" code Oleg Nesterov
2013-08-03 19:05 ` Kees Cook
2013-08-04 14:35 ` Oleg Nesterov
2013-08-04 17:13 ` Kees Cook
2013-08-01 19:05 ` [PATCH 2/3] exec: kill "int depth" in search_binary_handler() Oleg Nesterov
2013-08-03 18:28 ` Kees Cook
2013-08-03 18:55 ` Oleg Nesterov [this message]
2013-08-03 19:31 ` [PATCH v2 " Kees Cook
2013-08-01 19:05 ` [PATCH 3/3] exec: proc_exec_connector() should be called only once Oleg Nesterov
2013-08-03 19:10 ` Kees Cook
2013-08-02 14:09 ` [PATCH 0/3] exec: minor cleanups + minor fix Oleg Nesterov
2013-08-02 14:38 ` Zach Levis
2013-08-04 16:30 ` Oleg Nesterov
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=20130803185534.GA7452@redhat.com \
--to=oleg@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
--cc=zbr@ioremap.net \
--cc=zml@linux.vnet.ibm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox