Re: CVE-2022-49761: btrfs: always report error in run_one_delayed_ref()

[David Sterba <dsterba@suse.cz>]

On Thu, Mar 27, 2025 at 05:43:19PM +0100, Greg Kroah-Hartman wrote:
> Description
> ===========
> 
> In the Linux kernel, the following vulnerability has been resolved:
> 
> btrfs: always report error in run_one_delayed_ref()
> 
> Currently we have a btrfs_debug() for run_one_delayed_ref() failure, but
> if end users hit such problem, there will be no chance that
> btrfs_debug() is enabled.  This can lead to very little useful info for
> debugging.
> 
> This patch will:
> 
> - Add extra info for error reporting
>   Including:
>   * logical bytenr
>   * num_bytes
>   * type
>   * action
>   * ref_mod
> 
> - Replace the btrfs_debug() with btrfs_err()
> 
> - Move the error reporting into run_one_delayed_ref()
>   This is to avoid use-after-free, the @node can be freed in the caller.
> 
> This error should only be triggered at most once.
> 
> As if run_one_delayed_ref() failed, we trigger the error message, then
> causing the call chain to error out:
> 
> btrfs_run_delayed_refs()
> `- btrfs_run_delayed_refs()
>    `- btrfs_run_delayed_refs_for_head()
>       `- run_one_delayed_ref()
> 
> And we will abort the current transaction in btrfs_run_delayed_refs().
> If we have to run delayed refs for the abort transaction,
> run_one_delayed_ref() will just cleanup the refs and do nothing, thus no
> new error messages would be output.
> 
> The Linux kernel CVE team has assigned CVE-2022-49761 to this issue.

I'm disputing this CVE, there is no vulnerability. The code moves a
debugging print and makes it a more verbose error but does not have any
other functional change. Specifically it does not extend error handling
in any sensible way.

There is no apparent _vulnerability_, the patch was in stable likely
because it adds some user convenience, but thre's no Fixes nor CC:stable
tags so it was probably picked by AUTOSEL. Please reject the CVE, thanks.