CVE-2026-68167

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: do not try compression for data reloc inodes<br /> <br /> [BUG]<br /> There is a syzbot report that the check inside get_new_location()<br /> triggered:<br /> <br /> BTRFS info (device loop0): found 31 extents, stage: move data extents<br /> BTRFS info (device loop0): leaf 8908800 gen 16 total ptrs 28 free space 1676 owner 18446744073709551607<br /> item 0 key (256 INODE_ITEM 0) itemoff 3835 itemsize 160<br /> inode generation 5 transid 0 size 0 nbytes 0<br /> block group 0 mode 40755 links 1 uid 0 gid 0<br /> rdev 0 sequence 0 flags 0x0<br /> atime 1669132761.0<br /> ctime 1669132761.0<br /> mtime 1669132761.0<br /> otime 0.0<br /> item 1 key (256 INODE_REF 256) itemoff 3823 itemsize 12<br /> index 0 name_len 2<br /> item 2 key (258 INODE_ITEM 0) itemoff 3663 itemsize 160<br /> inode generation 1 transid 16 size 733184 nbytes 106496<br /> block group 0 mode 100600 links 0 uid 0 gid 0<br /> rdev 0 sequence 24 flags 0x18<br /> item 3 key (258 EXTENT_DATA 0) itemoff 3595 itemsize 68<br /> generation 16 type 0<br /> inline extent data size 47 ram_bytes 4096 compression 1<br /> [...]<br /> item 27 key (18446744073709551611 ORPHAN_ITEM 258) itemoff 2376 itemsize 0<br /> BTRFS error (device loop0): unexpected non-zero offset in file extent item for data reloc inode 258 key offset 0 offset 9277520992061368337<br /> ------------[ cut here ]------------<br /> btrfs_abort_should_print_stack(__error)<br /> <br /> [CAUSE]<br /> The above dump tree shows the first file extent item is inlined, which<br /> should make no sense for data reloc inodes, as such inodes just<br /> represent where the data extents are in the relocation destination chunk.<br /> <br /> However the relocation path preallocates space for each block,<br /> then dirties them, cluster by cluster.<br /> It&amp;#39;s possible to have a single block at the beginning of the block<br /> group, and no other block in the same cluster.<br /> <br /> So relocation will preallocate a file extent for that block and dirty<br /> the first block. Then memory pressure forces the data reloc inode to be<br /> written back, before any other blocks are dirtied/allocated.<br /> <br /> Finally commit 3eaf5f082c4c ("btrfs: extract inlined creation into a dedicated<br /> delalloc helper") changed the sequence of delalloc. Before that commit we<br /> always tried NOCOW first, so that dirtied block would be written back into<br /> the preallocated space, and appear as a regular extent.<br /> <br /> But with that commit, we always try inline first, and since compression<br /> is forced, we try compressing the first block, and then inline the<br /> compressed data, resulting in the above inlined file extent in the data<br /> reloc tree.<br /> <br /> Then the check in get_new_location() will check the file offset, without<br /> checking if the file extent is inlined or not, resulting in the above<br /> failure.<br /> <br /> [FIX]<br /> Do not allow compression for data reloc inodes.<br /> <br /> Since data reloc inode sizes are always block aligned, as long as we do<br /> not compress, @data_len will always be at least one block, and<br /> that will cause can_cow_file_range_inline() to return false, thus no<br /> inlined extent will be created.