CVE-2026-68167 in Linux
Summary
by MITRE • 08/10/2026
In the Linux kernel, the following vulnerability has been resolved:
btrfs: do not try compression for data reloc inodes
[BUG]
There is a syzbot report that the check inside get_new_location() triggered:
BTRFS info (device loop0): found 31 extents, stage: move data extents BTRFS info (device loop0): leaf 8908800 gen 16 total ptrs 28 free space 1676 owner 18446744073709551607 item 0 key (256 INODE_ITEM 0) itemoff 3835 itemsize 160 inode generation 5 transid 0 size 0 nbytes 0 block group 0 mode 40755 links 1 uid 0 gid 0 rdev 0 sequence 0 flags 0x0 atime 1669132761.0 ctime 1669132761.0 mtime 1669132761.0 otime 0.0 item 1 key (256 INODE_REF 256) itemoff 3823 itemsize 12 index 0 name_len 2 item 2 key (258 INODE_ITEM 0) itemoff 3663 itemsize 160 inode generation 1 transid 16 size 733184 nbytes 106496 block group 0 mode 100600 links 0 uid 0 gid 0 rdev 0 sequence 24 flags 0x18 item 3 key (258 EXTENT_DATA 0) itemoff 3595 itemsize 68 generation 16 type 0 inline extent data size 47 ram_bytes 4096 compression 1 [...]
item 27 key (18446744073709551611 ORPHAN_ITEM 258) itemoff 2376 itemsize 0 BTRFS error (device loop0): unexpected non-zero offset in file extent item for data reloc inode 258 key offset 0 offset 9277520992061368337 ------------[ cut here ]------------
btrfs_abort_should_print_stack(__error)
[CAUSE]
The above dump tree shows the first file extent item is inlined, which should make no sense for data reloc inodes, as such inodes just represent where the data extents are in the relocation destination chunk.
However the relocation path preallocates space for each block, then dirties them, cluster by cluster. It's possible to have a single block at the beginning of the block group, and no other block in the same cluster.
So relocation will preallocate a file extent for that block and dirty the first block. Then memory pressure forces the data reloc inode to be written back, before any other blocks are dirtied/allocated.
Finally commit 3eaf5f082c4c ("btrfs: extract inlined creation into a dedicated delalloc helper") changed the sequence of delalloc. Before that commit we always tried NOCOW first, so that dirtied block would be written back into the preallocated space, and appear as a regular extent.
But with that commit, we always try inline first, and since compression is forced, we try compressing the first block, and then inline the compressed data, resulting in the above inlined file extent in the data reloc tree.
Then the check in get_new_location() will check the file offset, without checking if the file extent is inlined or not, resulting in the above failure.
[FIX]
Do not allow compression for data reloc inodes.
Since data reloc inode sizes are always block aligned, as long as we do not compress, @data_len will always be at least one block, and that will cause can_cow_file_range_inline() to return false, thus no inlined extent will be created.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/10/2026
The vulnerability resides within the btrfs filesystem implementation in the Linux kernel, specifically concerning data relocation operations during filesystem maintenance. This issue manifests when the system attempts to move data extents from one location to another while maintaining filesystem integrity. The problem occurs during the relocation process where the kernel incorrectly handles compression for data relocation inodes, leading to unexpected behavior in extent management.
The technical flaw stems from a sequence of events that begins with the preallocation of space for blocks during the relocation process. When memory pressure forces the data relocation inode to be written back before additional blocks are dirtied or allocated, the system attempts to inline file extents. The commit 3eaf5f082c4c introduced a change in how delalloc operations are handled, prioritizing inline creation over NOCOW operations. This change creates a scenario where compression is forced for the first block, resulting in compressed inline data being stored within the relocation inode structure.
The operational impact of this vulnerability is significant as it causes kernel panics and system instability during btrfs filesystem operations. The error condition triggers when the get_new_location() function attempts to validate file offsets without considering whether the extent is inlined or not. This mismatch between expected and actual data structures leads to the btrfs_abort_should_print_stack() function being called, ultimately resulting in a kernel crash. The issue affects systems running btrfs filesystems that undergo regular maintenance operations involving data relocation.
This vulnerability aligns with CWE-129, which addresses improper validation of array indices, and demonstrates characteristics consistent with CWE-787, concerning out-of-bounds write conditions. From an ATT&CK perspective, this represents a kernel-level exploit vector that could potentially be leveraged for privilege escalation or system compromise. The fix implemented restricts compression capabilities specifically for data relocation inodes, ensuring that file extent sizes remain block-aligned and preventing the creation of inline extents during relocation operations.
The mitigation strategy focuses on preventing compression operations for data reloc inodes by modifying the kernel's behavior to ensure that data relocation inodes always maintain their block-aligned nature. This approach guarantees that the can_cow_file_range_inline() function will return false, thereby eliminating the possibility of creating inlined extents during relocation. The solution maintains system stability while preserving the integrity of btrfs filesystem operations and ensures that memory pressure scenarios do not result in kernel-level failures. This targeted fix addresses the root cause rather than merely patching symptoms, providing a robust resolution to the vulnerability while maintaining backward compatibility with existing btrfs functionality.
The resolution demonstrates proper defensive programming practices by establishing clear boundaries for when compression is allowed within specific inode types. The change prevents the problematic interaction between memory pressure conditions and compression logic during relocation operations, ensuring that the filesystem maintains consistent internal state throughout all phases of operation. This implementation aligns with kernel security best practices and reduces the attack surface for potential exploitation of filesystem-level vulnerabilities.