Message-ID: <2025091137-CVE-2025-39738-aed1@gregkh>
Date: Thu, 11 Sep 2025 18:52:39 +0200
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: linux-cve-announce@...r.kernel.org
Cc: Greg Kroah-Hartman <gregkh@...nel.org>
Subject: CVE-2025-39738: btrfs: do not allow relocation of partially dropped subvolumes

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

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

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

btrfs: do not allow relocation of partially dropped subvolumes

[BUG]
There is an internal report that balance triggered transaction abort,
with the following call trace:

  item 85 key (594509824 169 0) itemoff 12599 itemsize 33
          extent refs 1 gen 197740 flags 2
          ref#0: tree block backref root 7
  item 86 key (594558976 169 0) itemoff 12566 itemsize 33
          extent refs 1 gen 197522 flags 2
          ref#0: tree block backref root 7
 ...
 BTRFS error (device loop0): extent item not found for insert, bytenr 594526208 num_bytes 16384 parent 449921024 root_objectid 934 owner 1 offset 0
 BTRFS error (device loop0): failed to run delayed ref for logical 594526208 num_bytes 16384 type 182 action 1 ref_mod 1: -117
 ------------[ cut here ]------------
 BTRFS: Transaction aborted (error -117)
 WARNING: CPU: 1 PID: 6963 at ../fs/btrfs/extent-tree.c:2168 btrfs_run_delayed_refs+0xfa/0x110 [btrfs]

And btrfs check doesn't report anything wrong related to the extent
tree.

[CAUSE]
The cause is a little complex, firstly the extent tree indeed doesn't
have the backref for 594526208.

The extent tree only have the following two backrefs around that bytenr
on-disk:

        item 65 key (594509824 METADATA_ITEM 0) itemoff 13880 itemsize 33
                refs 1 gen 197740 flags TREE_BLOCK
                tree block skinny level 0
                (176 0x7) tree block backref root CSUM_TREE
        item 66 key (594558976 METADATA_ITEM 0) itemoff 13847 itemsize 33
                refs 1 gen 197522 flags TREE_BLOCK
                tree block skinny level 0
                (176 0x7) tree block backref root CSUM_TREE

But the such missing backref item is not an corruption on disk, as the
offending delayed ref belongs to subvolume 934, and that subvolume is
being dropped:

        item 0 key (934 ROOT_ITEM 198229) itemoff 15844 itemsize 439
                generation 198229 root_dirid 256 bytenr 10741039104 byte_limit 0 bytes_used 345571328
                last_snapshot 198229 flags 0x1000000000001(RDONLY) refs 0
                drop_progress key (206324 EXTENT_DATA 2711650304) drop_level 2
                level 2 generation_v2 198229

And that offending tree block 594526208 is inside the dropped range of
that subvolume.  That explains why there is no backref item for that
bytenr and why btrfs check is not reporting anything wrong.

But this also shows another problem, as btrfs will do all the orphan
subvolume cleanup at a read-write mount.

So half-dropped subvolume should not exist after an RW mount, and
balance itself is also exclusive to subvolume cleanup, meaning we
shouldn't hit a subvolume half-dropped during relocation.

The root cause is, there is no orphan item for this subvolume.
In fact there are 5 subvolumes from around 2021 that have the same
problem.

It looks like the original report has some older kernels running, and
caused those zombie subvolumes.

Thankfully upstream commit 8d488a8c7ba2 ("btrfs: fix subvolume/snapshot
deletion not triggered on mount") has long fixed the bug.

[ENHANCEMENT]
For repairing such old fs, btrfs-progs will be enhanced.

Considering how delayed the problem will show up (at run delayed ref
time) and at that time we have to abort transaction already, it is too
late.

Instead here we reject any half-dropped subvolume for reloc tree at the
earliest time, preventing confusion and extra time wasted on debugging
similar bugs.

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


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

	Fixed in 5.15.190 with commit fa086b1398cf7e5f7dee7241bd5f2855cb5df8dc
	Fixed in 6.1.149 with commit fcb1f77b8ed8795608ca7a1f6505e2b07236c1f3
	Fixed in 6.6.103 with commit f83d4c81bda3b7d1813268ab77408f7a0ce691ff
	Fixed in 6.12.43 with commit 39a93e1c9dbf7e11632efeb20fcf0fc1dcf64d51
	Fixed in 6.15.11 with commit 125e94a4b76b7b75d194f85bedd628097d2121f0
	Fixed in 6.16.2 with commit 4e403bd8e127d40dc7c05f06ee969c1ba1537ec5
	Fixed in 6.17-rc2 with commit 4289b494ac553e74e86fed1c66b2bf9530bc1082

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-39738
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/relocation.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/fa086b1398cf7e5f7dee7241bd5f2855cb5df8dc
	https://git.kernel.org/stable/c/fcb1f77b8ed8795608ca7a1f6505e2b07236c1f3
	https://git.kernel.org/stable/c/f83d4c81bda3b7d1813268ab77408f7a0ce691ff
	https://git.kernel.org/stable/c/39a93e1c9dbf7e11632efeb20fcf0fc1dcf64d51
	https://git.kernel.org/stable/c/125e94a4b76b7b75d194f85bedd628097d2121f0
	https://git.kernel.org/stable/c/4e403bd8e127d40dc7c05f06ee969c1ba1537ec5
	https://git.kernel.org/stable/c/4289b494ac553e74e86fed1c66b2bf9530bc1082

Powered by blists - more mailing lists