All of lore.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Sasha Levin <levinsasha928@gmail.com>
Cc: linux-fsdevel@vger.kernel.org,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: vfs: INFO: possible circular locking dependency detected
Date: Wed, 9 May 2012 17:12:03 +0100	[thread overview]
Message-ID: <20120509161203.GK22082@ZenIV.linux.org.uk> (raw)
In-Reply-To: <1336577114.3638.23.camel@lappy>

On Wed, May 09, 2012 at 05:25:14PM +0200, Sasha Levin wrote:
> Hi all,
> 
> I've started seeing the following warning while fuzzing inside a KVM guest with the latest -next:

[->read() may grab ->cred_guard_mutex, but it may itself be called by
prepare_binprm() after having ->cred_guard_mutex grabbed]

Nasty, that...  What's more, it's not just prepare_binprm() itself -
->load_binary() might end up calling read(); it doesn't have to
limit itself to mmap(), so essentially anything that can be grabbed
by ->read() of a regular file might nest under ->cred_guard_mutex.

	AFAICS, /proc/*/stack, /proc/*/syscall, /proc/*/personality,
/proc/*/io_accounting, /proc/*/auxv, /proc/*/environ, /proc/*/*maps
and /proc/*/pagemap have ->cred_guard_mutex grabbed on read.  seq_file
is a red herring here - io_accounting has the same issue and it does
things directly, without seq_read().

	It's not a realistic attack, fortunately, since you need root
to get past open_exec() on any of those...  Wait.  How _did_ you get
past open_exec(), anyway?  MAY_EXEC is not supposed to be granted on
anything that has no exec bits at all and AFAICS none of those files
have them.

  reply	other threads:[~2012-05-09 16:12 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-09 15:25 vfs: INFO: possible circular locking dependency detected Sasha Levin
2012-05-09 16:12 ` Al Viro [this message]
2012-05-09 16:23   ` Sasha Levin
2012-05-09 16:28     ` Al Viro
2012-05-09 16:36       ` Sasha Levin
2012-05-09 16:37       ` Al Viro
2012-05-09 17:13         ` Sasha Levin
2012-05-09 18:49           ` Dave Jones
2012-05-09 18:49             ` Dave Jones
2012-05-09 16:25   ` Al Viro

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=20120509161203.GK22082@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=levinsasha928@gmail.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /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.