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

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

Message-ID: <2025033118-hardship-reliant-2f7a@gregkh>
Date: Mon, 31 Mar 2025 20:43:02 +0100
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-2022-49761: btrfs: always report error in
 run_one_delayed_ref()

On Mon, Mar 31, 2025 at 08:03:17PM +0200, David Sterba wrote:
> 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 text here is why a CVE was assigned for this, is this not a
use-after-free fix?

> > 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.

This was part of the big GSD import of security vulnerability
identifiers that cve.org is having us do.  I read the above text about a
use-after-free which is why I agreed with the original assignment of a
GSD id and gave it a CVE id.

If this isn't the case, I'll be glad to revoke it, but at least now you
know why it was assigned one :)

thanks,

greg k-h