CVE-2024-26726

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: don&amp;#39;t drop extent_map for free space inode on write error<br /> <br /> While running the CI for an unrelated change I hit the following panic<br /> with generic/648 on btrfs_holes_spacecache.<br /> <br /> assertion failed: block_start != EXTENT_MAP_HOLE, in fs/btrfs/extent_io.c:1385<br /> ------------[ cut here ]------------<br /> kernel BUG at fs/btrfs/extent_io.c:1385!<br /> invalid opcode: 0000 [#1] PREEMPT SMP NOPTI<br /> CPU: 1 PID: 2695096 Comm: fsstress Kdump: loaded Tainted: G W 6.8.0-rc2+ #1<br /> RIP: 0010:__extent_writepage_io.constprop.0+0x4c1/0x5c0<br /> Call Trace:<br /> <br /> extent_write_cache_pages+0x2ac/0x8f0<br /> extent_writepages+0x87/0x110<br /> do_writepages+0xd5/0x1f0<br /> filemap_fdatawrite_wbc+0x63/0x90<br /> __filemap_fdatawrite_range+0x5c/0x80<br /> btrfs_fdatawrite_range+0x1f/0x50<br /> btrfs_write_out_cache+0x507/0x560<br /> btrfs_write_dirty_block_groups+0x32a/0x420<br /> commit_cowonly_roots+0x21b/0x290<br /> btrfs_commit_transaction+0x813/0x1360<br /> btrfs_sync_file+0x51a/0x640<br /> __x64_sys_fdatasync+0x52/0x90<br /> do_syscall_64+0x9c/0x190<br /> entry_SYSCALL_64_after_hwframe+0x6e/0x76<br /> <br /> This happens because we fail to write out the free space cache in one<br /> instance, come back around and attempt to write it again. However on<br /> the second pass through we go to call btrfs_get_extent() on the inode to<br /> get the extent mapping. Because this is a new block group, and with the<br /> free space inode we always search the commit root to avoid deadlocking<br /> with the tree, we find nothing and return a EXTENT_MAP_HOLE for the<br /> requested range.<br /> <br /> This happens because the first time we try to write the space cache out<br /> we hit an error, and on an error we drop the extent mapping. This is<br /> normal for normal files, but the free space cache inode is special. We<br /> always expect the extent map to be correct. Thus the second time<br /> through we end up with a bogus extent map.<br /> <br /> Since we&amp;#39;re deprecating this feature, the most straightforward way to<br /> fix this is to simply skip dropping the extent map range for this failed<br /> range.<br /> <br /> I shortened the test by using error injection to stress the area to make<br /> it easier to reproduce. With this patch in place we no longer panic<br /> with my error injection test.