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:25:00 +0100 [thread overview]
Message-ID: <20120509162459.GL22082@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20120509161203.GK22082@ZenIV.linux.org.uk>
On Wed, May 09, 2012 at 05:12:03PM +0100, Al Viro wrote:
> 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.
FWIW, that's _probably_ a false positive, but I really wonder what has
triggered it. It would take seq_file-based file somewhere with _some_
exec bits set (otherwise it shouldn't have been seen by prepare_binprm()).
The file itself isn't one of those that grab ->cred_guard_mutex anywhere
in their ->read(), but since lockdep can't tell one seq_file from another,
we get the warning.
The interesting part is who the hell had managed to do executable
seq_file-based anything - false positive or not, it's almost certainly
a bug...
prev parent reply other threads:[~2012-05-09 16:25 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
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 [this message]
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=20120509162459.GL22082@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.