In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
btrfs: initialize inode mapping flags for cached inodes<\/p>\n
[BUG]
\nWhen running generic\/795 with 8K block size, 4K page size, the test
\nalways fails, triggering some ASSERT()s related to folio size:<\/p>\n
795 (241074): drop_caches: 3
\n 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)
\n ————[ cut here ]————
\n kernel BUG at extent_io.c:1404!
\n Oops: invalid opcode: 0000 [#1] SMP
\n CPU: 8 UID: 0 PID: 241105 Comm: fsstress Tainted: G OE 7.2.0-rc5-custom+ #442 PREEMPT(full) f4bfb352566f3949f29c233ce6f735050a03b245
\n Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE
\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02\/02\/2022
\n RIP: 0010:assert_folio_range.cold+0x3d\/0x3f [btrfs]
\n Call Trace:<\/p>\n
btrfs_read_folio+0x9e\/0x170 [btrfs 4cd1dd93b341b8ef766643f9512f4a86259567a3]
\n prepare_one_folio.constprop.0+0x104\/0x2a0 [btrfs 4cd1dd93b341b8ef766643f9512f4a86259567a3]
\n btrfs_buffered_write+0x285\/0xa50 [btrfs 4cd1dd93b341b8ef766643f9512f4a86259567a3]
\n btrfs_do_write_iter+0x1aa\/0x210 [btrfs 4cd1dd93b341b8ef766643f9512f4a86259567a3]
\n iter_file_splice_write+0x31a\/0x540
\n direct_splice_actor+0x53\/0x170
\n splice_direct_to_actor+0xe9\/0x240
\n do_splice_direct+0x76\/0xb0
\n vfs_copy_file_range+0x1fd\/0x630
\n __x64_sys_copy_file_range+0xf9\/0x220
\n do_syscall_64+0xe1\/0x790
\n entry_SYSCALL_64_after_hwframe+0x4b\/0x53<\/p>\n
—[ end trace 0000000000000000 ]—<\/p>\n
The ASSERT() itself is added by a later patch.
\nThe crash is triggered with that new debug patch, and without this fix.<\/p>\n
[CAUSE]
\nIn the above case, the start 16826368 is properly 8K aligned, but the
\nend (16830463 + 1) is not 8K aligned.
\nFurthermore the mapping’s minimal folio order is 0, not the expected 1
\nfor 8K block size with 4K page size.<\/p>\n
So this means some inodes do not have btrfs_set_inode_mapping_order()
\ncalled on it.<\/p>\n
The missing btrfs_set_inode_mapping_order() call happens for cached
\ninodes, through the following events:<\/p>\n
– btrfs_create_new_inode() called for inode X
\n Which properly sets minimal folio order for the VFS inode.<\/p>\n
– btrfs_update_inode() called for inode X
\n Which calls btrfs_delayed_update_inode() to create a delayed_node
\n into root->delayed_nodes xarray.<\/p>\n
– Drop cache\/memory pressure, evicting in-memory inode X
\n Which evicted the inode X, but delayed_node is still in
\n root->delayed_nodes for future reuse.<\/p>\n
– btrfs_iget() for inode X called again<\/p>\n
btrfs_iget()
\n |- btrfs_iget_locked()
\n | |- iget5_locked_rcu()
\n | Which creates a new vfs_inode for btrfs, whose mapping still
\n | has the minimal order as 0.
\n |
\n |- btrfs_read_locked_inode()
\n |- btrfs_fill_inode()
\n | |- btrfs_get_delayed_node()
\n | Which found out the previous node, and use that delayed
\n | node to initialize the new inode.
\n |
\n |- filled = true;
\n |- if (filled) goto cache_index;
\n Which skips the btrfs_update_inode_mapping_flags() and
\n\tbtrfs_set_inode_mapping_order() calls.
\n\tSo the inode still has minimal folio order set as 0, not
\n\tthe required 1.<\/p>\n
Thus later page cache read will get a folio whose size is smaller than
\nblock size, as the mapping has its minimal folio order set as 0 not 1,
\nthen trigger the ASSERT().<\/p>\n
[FIX]
\nMove the btrfs_update_inode_mapping_flags() and
\nbtrfs_set_inode_mapping_order() calls under cache_index label,
\nso that the mapping flags and minimal folio order is always set
\nno matter if we have a cached inode.<\/p>\n","protected":false},"excerpt":{"rendered":"
In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
btrfs: initialize inode mapping flags for cached inodes<\/p>\n
[BUG]
\nWhen running generic\/795 with 8K block size, 4K page size, the test<\/p>\n","protected":false},"template":"","meta":[],"categories":[],"tags":[],"class_list":["post-3386","vuln","type-vuln","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln\/3386","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln"}],"about":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/types\/vuln"}],"wp:attachment":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=3386"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=3386"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=3386"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}