All of lore.kernel.org
 help / color / mirror / Atom feed
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.


  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.