CVE-2024-35784: btrfs: fix deadlock with fiemap and extent locking

Published May 17, 2024
·
Updated

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>] lockextent+0x28d/0x2f0 [<0>] btrfspagemkwrite+0x273/0x8a0 [<0>] dopagemkwrite+0x50/0xb0 [<0>] dofault+0xc1/0x7b0 [<0>] handlemmfault+0x2fa/0x460 [<0>] handlemmfault+0xa4/0x330 [<0>] douseraddrfault+0x1f4/0x800 [<0>] excpagefault+0x7c/0x1e0 [<0>] asmexcpagefault+0x26/0x30 [<0>] repmovsalternative+0x33/0x70 [<0>] copytouser+0x49/0x70 [<0>] fiemapfillnextextent+0xc8/0x120 [<0>] emitfiemapextent+0x4d/0xa0 [<0>] extentfiemap+0x7f8/0xad0 [<0>] btrfsfiemap+0x49/0x80 [<0>] x64sysioctl+0x3e1/0xb50 [<0>] dosyscall64+0x94/0x1a0 [<0>] entrySYSCALL64afterhwframe+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.

Affected Software

7 affected components
Linux Linux kernel<6.6.24
Linux Linux kernel>=6.7<6.7.12
Linux Linux kernel=6.8-rc1
Linux Linux kernel=6.8-rc2
Linux Linux kernel=6.8-rc3
Linux Linux kernel=6.8-rc4
Linux Linux kernel=6.8-rc5

Event History

May 17, 2024
CVE Published
via MITRE·12:24 PM
Data Sourced
via MITRE·12:24 PM
Description
Data Sourced
via NVD·01:15 PM
Description

Frequently Asked Questions

1

What is the severity of CVE-2024-35784?

CVE-2024-35784 is classified as a moderate severity vulnerability in the Linux kernel.

2

How do I fix CVE-2024-35784?

To fix CVE-2024-35784, ensure your Linux kernel version is updated to 6.6.24 or above, or one of the 6.8 release candidates.

3

What components are affected by CVE-2024-35784?

CVE-2024-35784 affects the Linux kernel, specifically versions prior to 6.6.24 and between 6.7.0 to 6.7.12, as well as 6.8 release candidates.

4

Is CVE-2024-35784 related to data corruption?

CVE-2024-35784 does not directly relate to data corruption but addresses a deadlock issue in the btrfs file system.

5

What is the vulnerability type of CVE-2024-35784?

CVE-2024-35784 is classified under deadlock vulnerabilities due to extent locking issues.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203