linux-kernel - 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 for Android: free password hash cracker in your pocket

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

Message-ID: <20240729205503.GT17473@twin.jikos.cz>
Date: Mon, 29 Jul 2024 22:55:03 +0200
From: David Sterba <dsterba@...e.cz>
To: cve@...nel.org, linux-kernel@...r.kernel.org
Cc: linux-cve-announce@...r.kernel.org,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: CVE-2024-41067: btrfs: scrub: handle RST lookup error correctly

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