Description

In the Linux kernel, the following vulnerability has been resolved: btrfs: initialize inode mapping flags for cached inodes [BUG] When running generic/795 with 8K block size, 4K page size, the test always fails, triggering some ASSERT()s related to folio size: 795 (241074): drop_caches: 3 assertion failed: IS_ALIGNED(start, blocksize) && IS_ALIGNED(end + 1, blocksize), in extent_io.c:1404 (blocksize=8192 root=262 ino=258 start=16826368 end=16830463 mapping min order=0) ------------[ cut here ]------------ kernel BUG at extent_io.c:1404! Oops: invalid opcode: 0000 [#1] SMP CPU: 8 UID: 0 PID: 241105 Comm: fsstress Tainted: G OE 7.2.0-rc5-custom+ #442 PREEMPT(full) f4bfb352566f3949f29c233ce6f735050a03b245 Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022 RIP: 0010:assert_folio_range.cold+0x3d/0x3f [btrfs] Call Trace: <TASK> btrfs_read_folio+0x9e/0x170 [btrfs 4cd1dd93b341b8ef766643f9512f4a86259567a3] prepare_one_folio.constprop.0+0x104/0x2a0 [btrfs 4cd1dd93b341b8ef766643f9512f4a86259567a3] btrfs_buffered_write+0x285/0xa50 [btrfs 4cd1dd93b341b8ef766643f9512f4a86259567a3] btrfs_do_write_iter+0x1aa/0x210 [btrfs 4cd1dd93b341b8ef766643f9512f4a86259567a3] iter_file_splice_write+0x31a/0x540 direct_splice_actor+0x53/0x170 splice_direct_to_actor+0xe9/0x240 do_splice_direct+0x76/0xb0 vfs_copy_file_range+0x1fd/0x630 __x64_sys_copy_file_range+0xf9/0x220 do_syscall_64+0xe1/0x790 entry_SYSCALL_64_after_hwframe+0x4b/0x53 </TASK> ---[ end trace 0000000000000000 ]--- The ASSERT() itself is added by a later patch. The crash is triggered with that new debug patch, and without this fix. [CAUSE] In the above case, the start 16826368 is properly 8K aligned, but the end (16830463 + 1) is not 8K aligned. Furthermore the mapping's minimal folio order is 0, not the expected 1 for 8K block size with 4K page size. So this means some inodes do not have btrfs_set_inode_mapping_order() called on it. The missing btrfs_set_inode_mapping_order() call happens for cached inodes, through the following events: - btrfs_create_new_inode() called for inode X Which properly sets minimal folio order for the VFS inode. - btrfs_update_inode() called for inode X Which calls btrfs_delayed_update_inode() to create a delayed_node into root->delayed_nodes xarray. - Drop cache/memory pressure, evicting in-memory inode X Which evicted the inode X, but delayed_node is still in root->delayed_nodes for future reuse. - btrfs_iget() for inode X called again btrfs_iget() |- btrfs_iget_locked() | |- iget5_locked_rcu() | Which creates a new vfs_inode for btrfs, whose mapping still | has the minimal order as 0. | |- btrfs_read_locked_inode() |- btrfs_fill_inode() | |- btrfs_get_delayed_node() | Which found out the previous node, and use that delayed | node to initialize the new inode. | |- filled = true; |- if (filled) goto cache_index; Which skips the btrfs_update_inode_mapping_flags() and btrfs_set_inode_mapping_order() calls. So the inode still has minimal folio order set as 0, not the required 1. Thus later page cache read will get a folio whose size is smaller than block size, as the mapping has its minimal folio order set as 0 not 1, then trigger the ASSERT(). [FIX] Move the btrfs_update_inode_mapping_flags() and btrfs_set_inode_mapping_order() calls under cache_index label, so that the mapping flags and minimal folio order is always set no matter if we have a cached inode.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.8",
  "pubDate": "2026-09-03T13:06:12.200Z",
  "pubdate": "2026-09-03T13:06:12.200Z",
  "executiveSummary": "This vulnerability is an improper initialization of inode mapping flags within the Btrfs file system, specifically affecting cached inodes when using block sizes larger than the system page size (e.g., 8K block size with 4K page size).\nThe flaw occurs during the inode loading process, where Btrfs fails to set the required minimal folio order for cached inodes that retain delayed nodes after eviction.\nThis failure leads to a mismatch between the expected block alignment and the actual folio size managed by the inode mapping, resulting in kernel assertion failures, system panics, and potential instability.\nThe issue primarily impacts environments where block sizes exceed the kernel page size, causing critical errors during buffered writes or file range operations.\nWhile this is a functional bug in the kernel, it represents a denial-of-service vector where a local attacker can trigger kernel crashes by manipulating cached inode states during disk I/O operations.",
  "technicalDetails": "The vulnerability resides in the Btrfs inode instantiation logic within the Linux kernel. Specifically, the function btrfs_read_locked_inode fails to consistently invoke btrfs_set_inode_mapping_order and btrfs_update_inode_mapping_flags when retrieving inodes from the cache.\nThe root cause is a logic flow error in btrfs_fill_inode. When an inode is evicted from memory but its associated 'delayed_node' persists in the root->delayed_nodes xarray, a subsequent btrfs_iget() call successfully reattaches the existing delayed_node. Due to the placement of the 'cache_index' label in the code, the initialization of mapping flags and folio order requirements is bypassed.\nIn systems configured with 8K block sizes on 4K page size architectures, the kernel expects inodes to enforce a minimum folio order of 1 to ensure that page cache operations are properly aligned with the file system block size. Because the bypassed functions are responsible for setting these flags, the mapping defaults to a minimal folio order of 0.\nThe attack flow involves: 1) Creating an inode that forces the creation of a delayed_node. 2) Forcing the inode out of memory (via memory pressure or drop_caches). 3) Re-accessing the inode so that btrfs_fill_inode retrieves the stale delayed_node. 4) Executing a file operation (e.g., copy_file_range or buffered write) that triggers range verification logic.\nDuring these operations, the system performs an alignment check (assert_folio_range) which compares the expected block alignment against the inode's misconfigured folio mapping. Because the mapping flags indicate a 0-order folio instead of the required 1-order, the check fails, triggering a BUG() condition and a kernel panic.\nThis vulnerability is triggered locally through normal file system interaction and does not require elevated network privileges. However, the requirement for specific block-to-page-size ratios limits the scope of affected systems to those utilizing non-default block sizes where such misalignment is permissible or tested."
}