CVE-2025-39738

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: do not allow relocation of partially dropped subvolumes<br /> <br /> [BUG]<br /> There is an internal report that balance triggered transaction abort,<br /> with the following call trace:<br /> <br /> item 85 key (594509824 169 0) itemoff 12599 itemsize 33<br /> extent refs 1 gen 197740 flags 2<br /> ref#0: tree block backref root 7<br /> item 86 key (594558976 169 0) itemoff 12566 itemsize 33<br /> extent refs 1 gen 197522 flags 2<br /> ref#0: tree block backref root 7<br /> ...<br /> BTRFS error (device loop0): extent item not found for insert, bytenr 594526208 num_bytes 16384 parent 449921024 root_objectid 934 owner 1 offset 0<br /> BTRFS error (device loop0): failed to run delayed ref for logical 594526208 num_bytes 16384 type 182 action 1 ref_mod 1: -117<br /> ------------[ cut here ]------------<br /> BTRFS: Transaction aborted (error -117)<br /> WARNING: CPU: 1 PID: 6963 at ../fs/btrfs/extent-tree.c:2168 btrfs_run_delayed_refs+0xfa/0x110 [btrfs]<br /> <br /> And btrfs check doesn&amp;#39;t report anything wrong related to the extent<br /> tree.<br /> <br /> [CAUSE]<br /> The cause is a little complex, firstly the extent tree indeed doesn&amp;#39;t<br /> have the backref for 594526208.<br /> <br /> The extent tree only have the following two backrefs around that bytenr<br /> on-disk:<br /> <br /> item 65 key (594509824 METADATA_ITEM 0) itemoff 13880 itemsize 33<br /> refs 1 gen 197740 flags TREE_BLOCK<br /> tree block skinny level 0<br /> (176 0x7) tree block backref root CSUM_TREE<br /> item 66 key (594558976 METADATA_ITEM 0) itemoff 13847 itemsize 33<br /> refs 1 gen 197522 flags TREE_BLOCK<br /> tree block skinny level 0<br /> (176 0x7) tree block backref root CSUM_TREE<br /> <br /> But the such missing backref item is not an corruption on disk, as the<br /> offending delayed ref belongs to subvolume 934, and that subvolume is<br /> being dropped:<br /> <br /> item 0 key (934 ROOT_ITEM 198229) itemoff 15844 itemsize 439<br /> generation 198229 root_dirid 256 bytenr 10741039104 byte_limit 0 bytes_used 345571328<br /> last_snapshot 198229 flags 0x1000000000001(RDONLY) refs 0<br /> drop_progress key (206324 EXTENT_DATA 2711650304) drop_level 2<br /> level 2 generation_v2 198229<br /> <br /> And that offending tree block 594526208 is inside the dropped range of<br /> that subvolume. That explains why there is no backref item for that<br /> bytenr and why btrfs check is not reporting anything wrong.<br /> <br /> But this also shows another problem, as btrfs will do all the orphan<br /> subvolume cleanup at a read-write mount.<br /> <br /> So half-dropped subvolume should not exist after an RW mount, and<br /> balance itself is also exclusive to subvolume cleanup, meaning we<br /> shouldn&amp;#39;t hit a subvolume half-dropped during relocation.<br /> <br /> The root cause is, there is no orphan item for this subvolume.<br /> In fact there are 5 subvolumes from around 2021 that have the same<br /> problem.<br /> <br /> It looks like the original report has some older kernels running, and<br /> caused those zombie subvolumes.<br /> <br /> Thankfully upstream commit 8d488a8c7ba2 ("btrfs: fix subvolume/snapshot<br /> deletion not triggered on mount") has long fixed the bug.<br /> <br /> [ENHANCEMENT]<br /> For repairing such old fs, btrfs-progs will be enhanced.<br /> <br /> Considering how delayed the problem will show up (at run delayed ref<br /> time) and at that time we have to abort transaction already, it is too<br /> late.<br /> <br /> Instead here we reject any half-dropped subvolume for reloc tree at the<br /> earliest time, preventing confusion and extra time wasted on debugging<br /> similar bugs.