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

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

[David Sterba]

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.

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

[Greg Kroah-Hartman]

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