From: Jan Kara <jack@suse.cz>
To: Sasha Levin <sashal@kernel.org>
Cc: Jan Kara <jack@suse.cz>,
linux-kernel@vger.kernel.org, stable@vger.kernel.org,
syzbot+10007d66ca02b08f0e60@syzkaller.appspotmail.com,
Jens Axboe <axboe@kernel.dk>,
linux-block@vger.kernel.org
Subject: Re: [PATCH AUTOSEL 5.1 35/70] loop: Don't change loop device under exclusive opener
Date: Thu, 20 Jun 2019 11:08:27 +0200 [thread overview]
Message-ID: <20190620090827.GJ13630@quack2.suse.cz> (raw)
In-Reply-To: <20190619201136.GD2226@sasha-vm>
On Wed 19-06-19 16:11:36, Sasha Levin wrote:
> On Mon, Jun 10, 2019 at 11:00:13AM +0200, Jan Kara wrote:
> > On Sat 08-06-19 07:39:14, Sasha Levin wrote:
> > > From: Jan Kara <jack@suse.cz>
> > >
> > > [ Upstream commit 33ec3e53e7b1869d7851e59e126bdb0fe0bd1982 ]
> >
> > Please don't push this to stable kernels because...
>
> I've dropped this, but...
OK, thanks.
> > > [Deliberately chosen not to CC stable as a user with priviledges to
> > > trigger this race has other means of taking the system down and this
> > > has a potential of breaking some weird userspace setup]
> >
> > ... of this. Thanks!
>
> Can't this be triggered by an "innocent" user, rather as part of an
> attack? Why can't this race happen during regular usage?
Well, the problem happens when mount happens on loop device when someone
modifies the backing file of the loop device. So for this to be
triggerable, you have to have control over assignment of backing files to
loop devices (you have to be owner of these loop devices to be able to do
this - pretty much means root in most setups) and be able to trigger mount
on this device. If you have these capabilities, there are much more
efficient ways to gain full administrator priviledges on the system,
deadlocking the kernel is thus the least of your worries.
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
next prev parent reply other threads:[~2019-06-20 9:08 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20190608113950.8033-1-sashal@kernel.org>
2019-06-08 11:39 ` [PATCH AUTOSEL 5.1 29/70] io_uring: Fix __io_uring_register() false success Sasha Levin
2019-06-08 11:39 ` [PATCH AUTOSEL 5.1 35/70] loop: Don't change loop device under exclusive opener Sasha Levin
2019-06-10 9:00 ` Jan Kara
2019-06-19 20:11 ` Sasha Levin
2019-06-20 9:08 ` Jan Kara [this message]
2019-06-08 11:39 ` [PATCH AUTOSEL 5.1 60/70] blk-mq: Fix memory leak in error handling Sasha Levin
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=20190620090827.GJ13630@quack2.suse.cz \
--to=jack@suse.cz \
--cc=axboe@kernel.dk \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sashal@kernel.org \
--cc=stable@vger.kernel.org \
--cc=syzbot+10007d66ca02b08f0e60@syzkaller.appspotmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox