linux-kernel - Re: kernel BUG at fs/btrfs/volumes.c:LINE!

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20190611100153.GD24160@twin.jikos.cz>
Date:   Tue, 11 Jun 2019 12:01:53 +0200
From:   David Sterba <dave@...os.cz>
To:     Eric Biggers <ebiggers@...nel.org>
Cc:     Chris Mason <clm@...com>, Josef Bacik <josef@...icpanda.com>,
        David Sterba <dsterba@...e.com>, linux-btrfs@...r.kernel.org,
        Dmitry Vyukov <dvyukov@...gle.com>,
        Anand Jain <anand.jain@...cle.com>,
        syzbot <syzbot+5b658d997a83984507a6@...kaller.appspotmail.com>,
        LKML <linux-kernel@...r.kernel.org>,
        syzkaller-bugs <syzkaller-bugs@...glegroups.com>
Subject: Re: kernel BUG at fs/btrfs/volumes.c:LINE!

On Mon, Jun 10, 2019 at 04:14:04PM -0700, Eric Biggers wrote:
> On Thu, Jun 07, 2018 at 06:52:13PM +0200, David Sterba wrote:
> > On Thu, Jun 07, 2018 at 06:28:02PM +0200, Dmitry Vyukov wrote:
> > > > Normally the GFP_NOFS allocations do not fail so I think the fuzzer
> > > > environment is tuned to allow that, which is fine for coverage but does
> > > > not happen in practice. This will be fixed eventually.
> > > 
> > > Isn't GFP_NOFS more restricted than normal allocations?  Are these
> > > allocations accounted against memcg? It's easy to fail any allocation
> > > within a memory container.
> > 
> > https://lwn.net/Articles/723317/ The 'too small to fail' and some
> > unwritten semantics of GFP_NOFS but I think you're right about the
> > memory controler that can fail any allocation though.
> > 
> > Error handling is being improved over time, the memory allocation
> > failures are in some cases hard and this one would need to update some
> > logic so it's not a oneliner.
> > 
> 
> This bug is still there.  In btrfs_close_one_device():
> 
> 	if (device->name) {
> 		name = rcu_string_strdup(device->name->str, GFP_NOFS);
> 		BUG_ON(!name); /* -ENOMEM */
> 		rcu_assign_pointer(new_device->name, name);
> 	}
> 
> It assumes that the memory allocation succeeded.
> 
> See syzbot report from v5.2-rc3 here: https://syzkaller.appspot.com/text?tag=CrashReport&x=16c839c1a00000
> 
> Is there any plan to fix this?

Yes there is, to avoid allocations when closing the device and tracking
the state in another way. As this has never been reported in practice
the priority to fix it is rather low so I can't give you an ETA.