CVE-2024-35784

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 dont have lockdep annotations with the extent locking so weve never noticed it.

Since were 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 mmaped. 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 dont 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 were searching the tree, so if an ordered extent updates in the middle of our fiemap call well 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 were checking to see if we need to set the delalloc flag.

With this patch applied we no longer deadlock with my testcase.

Weakness

The product does not properly acquire or release a lock on a resource, leading to unexpected resource state changes and behaviors.

Affected Software

Extended Description

Locking is a type of synchronization behavior that ensures that multiple independently-operating processes or threads do not interfere with each other when accessing the same resource. All processes/threads are expected to follow the same steps for locking. If these steps are not followed precisely - or if no locking is done at all - then another process/thread could modify the shared resource in a way that is not visible or predictable to the original process. This can lead to data or memory corruption, denial of service, etc.

Potential Mitigations

Related Attack Patterns

• https://cwe.mitre.org/data/definitions/25.html
• https://cwe.mitre.org/data/definitions/26.html
• https://cwe.mitre.org/data/definitions/27.html

References

• https://git.kernel.org/stable/c/89bca7fe6382d61e88c67a0b0e7bce315986fb8b
• https://git.kernel.org/stable/c/b0ad381fa7690244802aed119b478b4bdafc31dd
• https://git.kernel.org/stable/c/ded566b4637f1b6b4c9ba74e7d0b8493e93f19cf
• https://git.kernel.org/stable/c/89bca7fe6382d61e88c67a0b0e7bce315986fb8b
• https://git.kernel.org/stable/c/b0ad381fa7690244802aed119b478b4bdafc31dd
• https://git.kernel.org/stable/c/ded566b4637f1b6b4c9ba74e7d0b8493e93f19cf