From: Oleg Nesterov <oleg@redhat.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Andrew Morton <akpm@linux-foundation.org>,
Al Viro <viro@ZenIV.linux.org.uk>,
David Smith <dsmith@redhat.com>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Igor Zhbanov <i.zhbanov@samsung.com>,
Christoph Hellwig <hch@infradead.org>,
Paul Menage <menage@google.com>
Subject: Re: [RFC][PATCH] exec: Fix use after free of tracepoint trace_sched_process_exec
Date: Tue, 4 Feb 2014 20:00:07 +0100 [thread overview]
Message-ID: <20140204190007.GA8996@redhat.com> (raw)
In-Reply-To: <20140204120500.041b5175@gandalf.local.home>
On 02/04, Steven Rostedt wrote:
>
> Now to fix this we need to save the filename before calling
> search_binary_handler(). But we don't want to save it if we are not
> tracing. Why slow everyone else down?
Yes, but it would be much simpler to dup filename unconditionally.
Note also that in this case we can kill linux_binprm->tcomm[] and
simplify filename_to_taskname().
> This works, but is rather ugly.
Yes ;)
> Looking for any other suggestions here.
Perhaps we can change flush_old_exec() to do
if (!current->mm) {
bprm->filename = kstrdup(bprm->filename);
if (bprm->filename)
bprm->filename_was_dupped = true; // for free_bprm()
else
bprm->filename = "//enomem";
}
This won't penalize the normal exec, and this should fix the problem
afaics.
Perhaps, instead of "//enomem" flush_old_exec() should simply fail,
in this case we can kill bprm->tcomm[] too.
Oleg.
next prev parent reply other threads:[~2014-02-04 19:54 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-04 17:05 [RFC][PATCH] exec: Fix use after free of tracepoint trace_sched_process_exec Steven Rostedt
2014-02-04 19:00 ` Oleg Nesterov [this message]
2014-02-04 20:10 ` Steven Rostedt
2014-02-04 20:18 ` Linus Torvalds
2014-02-04 20:31 ` Steven Rostedt
2014-02-04 23:28 ` Steven Rostedt
2014-02-04 23:42 ` Steven Rostedt
2014-02-05 0:57 ` Linus Torvalds
2014-02-05 1:10 ` Al Viro
2014-02-05 3:37 ` Linus Torvalds
2014-02-05 13:52 ` Oleg Nesterov
2014-02-05 16:52 ` Linus Torvalds
2014-02-05 2:31 ` Steven Rostedt
2014-02-05 2:51 ` Steven Rostedt
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=20140204190007.GA8996@redhat.com \
--to=oleg@redhat.com \
--cc=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=dsmith@redhat.com \
--cc=hch@infradead.org \
--cc=i.zhbanov@samsung.com \
--cc=linux-kernel@vger.kernel.org \
--cc=menage@google.com \
--cc=rostedt@goodmis.org \
--cc=torvalds@linux-foundation.org \
--cc=viro@ZenIV.linux.org.uk \
/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.