linux-kernel - Re: [PATCH AUTOSEL 5.1 35/70] loop: Don't change loop device under exclusive opener

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20190620090827.GJ13630@quack2.suse.cz>
Date:   Thu, 20 Jun 2019 11:08:27 +0200
From:   Jan Kara <jack@...e.cz>
To:     Sasha Levin <sashal@...nel.org>
Cc:     Jan Kara <jack@...e.cz>, linux-kernel@...r.kernel.org,
        stable@...r.kernel.org,
        syzbot+10007d66ca02b08f0e60@...kaller.appspotmail.com,
        Jens Axboe <axboe@...nel.dk>, linux-block@...r.kernel.org
Subject: Re: [PATCH AUTOSEL 5.1 35/70] loop: Don't change loop device under
 exclusive opener

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@...e.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@...e.com>
SUSE Labs, CR