linux-cve-announce - Re: CVE-2024-41067: btrfs: scrub: handle RST lookup error correctly

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>] [day] [month] [year] [list]

Message-ID: <2024073030-vagabond-imprudent-8ea2@gregkh>
Date: Tue, 30 Jul 2024 06:53:40 +0200
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: David Sterba <dsterba@...e.cz>
Cc: cve@...nel.org, linux-kernel@...r.kernel.org,
	linux-cve-announce@...r.kernel.org
Subject: Re: CVE-2024-41067: btrfs: scrub: handle RST lookup error correctly

On Mon, Jul 29, 2024 at 10:55:03PM +0200, David Sterba wrote:
> On Mon, Jul 29, 2024 at 04:58:13PM +0200, Greg Kroah-Hartman wrote:
> > Description
> > ===========
> > 
> > In the Linux kernel, the following vulnerability has been resolved:
> > 
> > btrfs: scrub: handle RST lookup error correctly
> > 
> > [BUG]
> > When running btrfs/060 with forced RST feature, it would crash the
> > following ASSERT() inside scrub_read_endio():
> > 
> > 	ASSERT(sector_nr < stripe->nr_sectors);
> > 
> > Before that, we would have tree dump from
> > btrfs_get_raid_extent_offset(), as we failed to find the RST entry for
> > the range.
> > 
> > [CAUSE]
> > Inside scrub_submit_extent_sector_read() every time we allocated a new
> > bbio we immediately called btrfs_map_block() to make sure there was some
> > RST range covering the scrub target.
> > 
> > But if btrfs_map_block() fails, we immediately call endio for the bbio,
> > while the bbio is newly allocated, it's completely empty.
> > 
> > Then inside scrub_read_endio(), we go through the bvecs to find
> > the sector number (as bi_sector is no longer reliable if the bio is
> > submitted to lower layers).
> > 
> > And since the bio is empty, such bvecs iteration would not find any
> > sector matching the sector, and return sector_nr == stripe->nr_sectors,
> > triggering the ASSERT().
> > 
> > [FIX]
> > Instead of calling btrfs_map_block() after allocating a new bbio, call
> > btrfs_map_block() first.
> > 
> > Since our only objective of calling btrfs_map_block() is only to update
> > stripe_len, there is really no need to do that after btrfs_alloc_bio().
> > 
> > This new timing would avoid the problem of handling empty bbio
> > completely, and in fact fixes a possible race window for the old code,
> > where if the submission thread is the only owner of the pending_io, the
> > scrub would never finish (since we didn't decrease the pending_io
> > counter).
> > 
> > Although the root cause of RST lookup failure still needs to be
> > addressed.
> > 
> > The Linux kernel CVE team has assigned CVE-2024-41067 to this issue.
> 
> Please drop the CVE. It's a fix for feature that's still in development
> and is not enabled on production kernels (requires CONFIG_BTRFS_DEBUG).

We do not know people's use case, and can not "gate" CVE ids based on
difference config options like this.

> There was even a recent on-disk format change (mkfs required), this is
> not really for environments where security matters. Thanks.

It's a fix for a vulnerability, so I think it should stay assigned.  If
your system does not enable that config option, then there is nothing to
worry about, right?

thanks,

greg k-h