CVE-2025-39738
Unknown Unknown - Not Provided
BaseFortify

Publication date: 2025-09-11

Last updated on: 2025-11-03

Assigner: kernel.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.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2025-09-11
Last Modified
2025-11-03
Generated
2026-05-07
AI Q&A
2025-09-11
EPSS Evaluated
2026-05-05
NVD
CVE-2025-39738
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
linux kernel 6.1.153
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability involves the Btrfs filesystem in the Linux kernel, where relocation of partially dropped subvolumes is not allowed. The issue arises because some subvolumes that were only partially dropped (deleted) can cause balance operations to abort transactions due to missing backreferences in the extent tree. This happens because the subvolume is in a half-dropped state without an orphan item, leading to inconsistencies during relocation. The problem was fixed by ensuring that half-dropped subvolumes are rejected early during relocation, preventing transaction aborts and debugging difficulties.


How can this vulnerability impact me? :

This vulnerability can cause balance operations on Btrfs filesystems to abort transactions unexpectedly, potentially leading to filesystem operation failures or instability. It may result in delays or failures during filesystem maintenance tasks like relocation or cleanup of subvolumes, which could impact system reliability or data availability until the issue is resolved.


How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability relates to the btrfs filesystem and involves partially dropped subvolumes causing transaction aborts during balance operations. Detection involves monitoring for BTRFS errors such as 'extent item not found for insert' and 'Transaction aborted' messages in system logs. Running 'btrfs check' may not report issues related to this problem. Specific commands to detect this include checking kernel logs (e.g., 'dmesg | grep BTRFS') for error messages and inspecting subvolumes for half-dropped states. However, no explicit detection commands are provided in the available information.


What immediate steps should I take to mitigate this vulnerability?

Immediate mitigation involves ensuring your system is running a Linux kernel version that includes the upstream fix (commit 8d488a8c7ba2) which prevents subvolume/snapshot deletion issues on mount. Avoid running balance operations on filesystems with half-dropped subvolumes. Mount the filesystem read-write to trigger orphan subvolume cleanup. For older filesystems, use updated btrfs-progs tools that include enhancements to repair such issues. Rejecting half-dropped subvolumes early during relocation is part of the fix to prevent transaction aborts.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart