https://db.gcve.eu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Mon, 28 Sep 2026 07:33:24 +0000 https://db.gcve.eu/vuln/cve-2024-35784 <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>btrfs: fix deadlock with fiemap and extent locking</p> <p>While working on the patchset to remove extent locking I got a lockdep splat with fiemap and pagefaulting with my new extent lock replacement lock.</p> <p>This deadlock exists with our normal code, we just don&#39;t have lockdep annotations with the extent locking so we&#39;ve never noticed it.</p> <p>Since we&#39;re copying the fiemap extent to user space on every iteration we have the chance of pagefaulting. Because we hold the extent lock for the entire range we could mkwrite into a range in the file that we have mmap&#39;ed. This would deadlock with the following stack trace</p> <p>[&lt;0&gt;] lock_extent+0x28d/0x2f0 [&lt;0&gt;] btrfs_page_mkwrite+0x273/0x8a0 [&lt;0&gt;] do_page_mkwrite+0x50/0xb0 [&lt;0&gt;] do_fault+0xc1/0x7b0 [&lt;0&gt;] __handle_mm_fault+0x2fa/0x460 [&lt;0&gt;] handle_mm_fault+0xa4/0x330 [&lt;0&gt;] do_user_addr_fault+0x1f4/0x800 [&lt;0&gt;] exc_page_fault+0x7c/0x1e0 [&lt;0&gt;] asm_exc_page_fault+0x26/0x30 [&lt;0&gt;] rep_movs_alternative+0x33/0x70 [&lt;0&gt;] _copy_to_user+0x49/0x70 [&lt;0&gt;] fiemap_fill_next_extent+0xc8/0x120 [&lt;0&gt;] emit_fiemap_extent+0x4d/0xa0 [&lt;0&gt;] extent_fiemap+0x7f8/0xad0 [&lt;0&gt;] btrfs_fiemap+0x49/0x80 [&lt;0&gt;] __x64_sys_ioctl+0x3e1/0xb50 [&lt;0&gt;] do_syscall_64+0x94/0x1a0 [&lt;0&gt;] entry_SYSCALL_64_after_hwframe+0x6e/0x76</p> <p>I wrote an fstest to reproduce this deadlock without my replacement lock and verified that the deadlock exists with our existing locking.</p> <p>To fix this simply don&#39;t take the extent lock for the entire du…</p> <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>btrfs: fix deadlock with fiemap and extent locking</p> <p>While working on the patchset to remove extent locking I got a lockdep splat with fiemap and pagefaulting with my new extent lock replacement lock.</p> <p>This deadlock exists with our normal code, we just don&#39;t have lockdep annotations with the extent locking so we&#39;ve never noticed it.</p> <p>Since we&#39;re copying the fiemap extent to user space on every iteration we have the chance of pagefaulting. Because we hold the extent lock for the entire range we could mkwrite into a range in the file that we have mmap&#39;ed. This would deadlock with the following stack trace</p> <p>[&lt;0&gt;] lock_extent+0x28d/0x2f0 [&lt;0&gt;] btrfs_page_mkwrite+0x273/0x8a0 [&lt;0&gt;] do_page_mkwrite+0x50/0xb0 [&lt;0&gt;] do_fault+0xc1/0x7b0 [&lt;0&gt;] __handle_mm_fault+0x2fa/0x460 [&lt;0&gt;] handle_mm_fault+0xa4/0x330 [&lt;0&gt;] do_user_addr_fault+0x1f4/0x800 [&lt;0&gt;] exc_page_fault+0x7c/0x1e0 [&lt;0&gt;] asm_exc_page_fault+0x26/0x30 [&lt;0&gt;] rep_movs_alternative+0x33/0x70 [&lt;0&gt;] _copy_to_user+0x49/0x70 [&lt;0&gt;] fiemap_fill_next_extent+0xc8/0x120 [&lt;0&gt;] emit_fiemap_extent+0x4d/0xa0 [&lt;0&gt;] extent_fiemap+0x7f8/0xad0 [&lt;0&gt;] btrfs_fiemap+0x49/0x80 [&lt;0&gt;] __x64_sys_ioctl+0x3e1/0xb50 [&lt;0&gt;] do_syscall_64+0x94/0x1a0 [&lt;0&gt;] entry_SYSCALL_64_after_hwframe+0x6e/0x76</p> <p>I wrote an fstest to reproduce this deadlock without my replacement lock and verified that the deadlock exists with our existing locking.</p> <p>To fix this simply don&#39;t take the extent lock for the entire du…</p> https://db.gcve.eu/vuln/cve-2024-35784