Message-ID: <2025122457-CVE-2025-68359-c931@gregkh>
Date: Wed, 24 Dec 2025 11:35:04 +0100
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: linux-cve-announce@...r.kernel.org
Cc: Greg Kroah-Hartman <gregkh@...nel.org>
Subject: CVE-2025-68359: btrfs: fix double free of qgroup record after failure to add delayed ref head

From: Greg Kroah-Hartman <gregkh@...nel.org>

Description
===========

In the Linux kernel, the following vulnerability has been resolved:

btrfs: fix double free of qgroup record after failure to add delayed ref head

In the previous code it was possible to incur into a double kfree()
scenario when calling add_delayed_ref_head(). This could happen if the
record was reported to already exist in the
btrfs_qgroup_trace_extent_nolock() call, but then there was an error
later on add_delayed_ref_head(). In this case, since
add_delayed_ref_head() returned an error, the caller went to free the
record. Since add_delayed_ref_head() couldn't set this kfree'd pointer
to NULL, then kfree() would have acted on a non-NULL 'record' object
which was pointing to memory already freed by the callee.

The problem comes from the fact that the responsibility to kfree the
object is on both the caller and the callee at the same time. Hence, the
fix for this is to shift the ownership of the 'qrecord' object out of
the add_delayed_ref_head(). That is, we will never attempt to kfree()
the given object inside of this function, and will expect the caller to
act on the 'qrecord' object on its own. The only exception where the
'qrecord' object cannot be kfree'd is if it was inserted into the
tracing logic, for which we already have the 'qrecord_inserted_ret'
boolean to account for this. Hence, the caller has to kfree the object
only if add_delayed_ref_head() reports not to have inserted it on the
tracing logic.

As a side-effect of the above, we must guarantee that
'qrecord_inserted_ret' is properly initialized at the start of the
function, not at the end, and then set when an actual insert
happens. This way we avoid 'qrecord_inserted_ret' having an invalid
value on an early exit.

The documentation from the add_delayed_ref_head() has also been updated
to reflect on the exact ownership of the 'qrecord' object.

The Linux kernel CVE team has assigned CVE-2025-68359 to this issue.


Affected and fixed versions
===========================

	Issue introduced in 6.12 with commit 6ef8fbce010421bf742b12b8f8f2b2d2ff154845 and fixed in 6.17.13 with commit 7617680769e3119dfb3b43a2b7c287ce2242211c
	Issue introduced in 6.12 with commit 6ef8fbce010421bf742b12b8f8f2b2d2ff154845 and fixed in 6.18.2 with commit 364685c4c2d9c9f4408d95451bcf42fdeebc3ebb
	Issue introduced in 6.12 with commit 6ef8fbce010421bf742b12b8f8f2b2d2ff154845 and fixed in 6.19-rc1 with commit 725e46298876a2cc1f1c3fb22ba69d29102c3ddf

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2025-68359
will be updated if fixes are backported, please check that for the most
up to date information about this issue.


Affected files
==============

The file(s) affected by this issue are:
	fs/btrfs/delayed-ref.c


Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/7617680769e3119dfb3b43a2b7c287ce2242211c
	https://git.kernel.org/stable/c/364685c4c2d9c9f4408d95451bcf42fdeebc3ebb
	https://git.kernel.org/stable/c/725e46298876a2cc1f1c3fb22ba69d29102c3ddf

Powered by blists - more mailing lists