All of lore.kernel.org
 help / color / mirror / Atom feed
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: Re: [PATCH 1/5] exec: move allow_write_access/fput to exec_binprm()
Date: Sun, 4 Aug 2013 16:48:47 +0200	[thread overview]
Message-ID: <20130804144847.GB18906@redhat.com> (raw)
In-Reply-To: <CAGXu5jKY1S7wxWCv6ZULU=rvp1fQ9KemcFZxY7ccoX06jdvP3w@mail.gmail.com>

On 08/03, Kees Cook wrote:
>
> On Fri, Aug 2, 2013 at 12:27 PM, Oleg Nesterov <oleg@redhat.com> wrote:
> > @@ -1455,6 +1451,11 @@ static int exec_binprm(struct linux_binprm *bprm)
> >                 ptrace_event(PTRACE_EVENT_EXEC, old_vpid);
> >                 current->did_exec = 1;
> >                 proc_exec_connector(current);
> > +
> > +               if (bprm->file) {
> > +                       allow_write_access(bprm->file);
> > +                       fput(bprm->file);
> > +               }
>
> Why not keep the bprm->file = NULL assignment?

Because it is no longer needed.

And now that we have the non-recursive exec_binprm() called right
before free_bprm() it is obvious that it won't be used again.

> Seems reasonable to
> keep that just to be avoid use-after-free accidents.

OK. I will add it back. With the comment to explain that this is
only to catch the possible problems.

I guess it would be better if I resend the whole series to avoid
the confusion. I am going to add your acks. It seems that you acked
everything except 1/3 in the previous series, perhaps you can ack
it too?

Thanks for review!

Oleg.


  reply	other threads:[~2013-08-04 14:54 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-02 19:27 [PATCH 0/5] exec: more cleanups Oleg Nesterov
2013-08-02 19:27 ` [PATCH 1/5] exec: move allow_write_access/fput to exec_binprm() Oleg Nesterov
2013-08-03 19:27   ` Kees Cook
2013-08-04 14:48     ` Oleg Nesterov [this message]
2013-08-02 19:27 ` [PATCH 2/5] exec: kill ->load_binary != NULL check in search_binary_handler() Oleg Nesterov
2013-08-02 19:27 ` [PATCH 3/5] exec: cleanup the CONFIG_MODULES logic Oleg Nesterov
2013-08-02 19:27 ` [PATCH 4/5] exec: don't retry if request_module() fails Oleg Nesterov
2013-08-02 19:27 ` [PATCH 5/5] exec: cleanup the error handling in search_binary_handler() Oleg Nesterov
2013-08-03 19:28 ` [PATCH 0/5] exec: more cleanups 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=20130804144847.GB18906@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 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.