Lucene search

K
ubuntucveUbuntu.comUB:CVE-2024-35784
HistoryMay 17, 2024 - 12:00 a.m.

CVE-2024-35784

2024-05-1700:00:00
ubuntu.com
ubuntu.com
3
linux kernel
btrfs
deadlock
cve-2024-35784
deadlock fix
fiemap
extent locking
pagefault
lockdep
delalloc.

AI Score

6.4

Confidence

High

EPSS

0

Percentile

15.5%

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

AI Score

6.4

Confidence

High

EPSS

0

Percentile

15.5%