CVE-2024-35784

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix deadlock with fiemap and extent locking<br /> <br /> While working on the patchset to remove extent locking I got a lockdep<br /> splat with fiemap and pagefaulting with my new extent lock replacement<br /> lock.<br /> <br /> This deadlock exists with our normal code, we just don&amp;#39;t have lockdep<br /> annotations with the extent locking so we&amp;#39;ve never noticed it.<br /> <br /> Since we&amp;#39;re copying the fiemap extent to user space on every iteration<br /> we have the chance of pagefaulting. Because we hold the extent lock for<br /> the entire range we could mkwrite into a range in the file that we have<br /> mmap&amp;#39;ed. This would deadlock with the following stack trace<br /> <br /> [] lock_extent+0x28d/0x2f0<br /> [] btrfs_page_mkwrite+0x273/0x8a0<br /> [] do_page_mkwrite+0x50/0xb0<br /> [] do_fault+0xc1/0x7b0<br /> [] __handle_mm_fault+0x2fa/0x460<br /> [] handle_mm_fault+0xa4/0x330<br /> [] do_user_addr_fault+0x1f4/0x800<br /> [] exc_page_fault+0x7c/0x1e0<br /> [] asm_exc_page_fault+0x26/0x30<br /> [] rep_movs_alternative+0x33/0x70<br /> [] _copy_to_user+0x49/0x70<br /> [] fiemap_fill_next_extent+0xc8/0x120<br /> [] emit_fiemap_extent+0x4d/0xa0<br /> [] extent_fiemap+0x7f8/0xad0<br /> [] btrfs_fiemap+0x49/0x80<br /> [] __x64_sys_ioctl+0x3e1/0xb50<br /> [] do_syscall_64+0x94/0x1a0<br /> [] entry_SYSCALL_64_after_hwframe+0x6e/0x76<br /> <br /> I wrote an fstest to reproduce this deadlock without my replacement lock<br /> and verified that the deadlock exists with our existing locking.<br /> <br /> To fix this simply don&amp;#39;t take the extent lock for the entire duration of<br /> the fiemap. This is safe in general because we keep track of where we<br /> are when we&amp;#39;re searching the tree, so if an ordered extent updates in<br /> the middle of our fiemap call we&amp;#39;ll still emit the correct extents<br /> because we know what offset we were on before.<br /> <br /> The only place we maintain the lock is searching delalloc. Since the<br /> delalloc stuff can change during writeback we want to lock the extent<br /> range so we have a consistent view of delalloc at the time we&amp;#39;re<br /> checking to see if we need to set the delalloc flag.<br /> <br /> With this patch applied we no longer deadlock with my testcase.