TLDRVuln - Cybersecurity Vulnerabilities Made Simple

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.