linux-kernel - Re: CVE-2022-49761: btrfs: always report error in run_one_delayed

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

Message-ID: <20250331180316.GJ32661@suse.cz>
Date: Mon, 31 Mar 2025 20:03:17 +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-2022-49761: btrfs: always report error in
 run_one_delayed_ref()

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.