btrfs: fix deadlock with fiemap and extent locking
Key facts
- Attack vector
- Local
- Privileges required
- Low
- User interaction
- None
- Attack complexity
- Low
- Impact type
- Denial of service
- Confidentiality · integrity · availability
- None · None · High
- Fix status
- Partial Red Hat: 2 without a fix
Attack profile from CVSS 3.1 · NVD. Fix status from CNA and Red Hat. Impact type from CWE-667 and the CVSS impact.
Summary
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.
Why it matters now
SSVC decision points
CISA ADP · SSVC 2.0.3
- Exploitation
- None
- Automatable
- No
- Technical impact
- Partial
The decision (Track, Attend, Act) also depends on your mission and well-being impact; see CISA's SSVC guide.
Affected products
| Vendor | Product | Affected versions | Fixed in | Status | Source |
|---|---|---|---|---|---|
| Linux | Linux | 2.6.29 and later | 6.1.191, 6.6.24, 6.7.12, 6.8 | Patch available | CNA |
- Linux VendorLinux Affected 2.6.29 and later Fixed in 6.1.191, 6.6.24, 6.7.12, 6.8 Patch available CNA
CPE configurations NVD · 6
| CPE | Versions | Role | Vendor |
|---|---|---|---|
| cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* | before 6.6.24; 6.7 to before 6.7.12 | Vulnerable | Linux |
| cpe:2.3:o:linux:linux_kernel:6.8:rc1:*:*:*:*:*:* | 6.8 rc1 | Vulnerable | Linux |
| cpe:2.3:o:linux:linux_kernel:6.8:rc2:*:*:*:*:*:* | 6.8 rc2 | Vulnerable | Linux |
| cpe:2.3:o:linux:linux_kernel:6.8:rc3:*:*:*:*:*:* | 6.8 rc3 | Vulnerable | Linux |
| cpe:2.3:o:linux:linux_kernel:6.8:rc4:*:*:*:*:*:* | 6.8 rc4 | Vulnerable | Linux |
| cpe:2.3:o:linux:linux_kernel:6.8:rc5:*:*:*:*:*:* | 6.8 rc5 | Vulnerable | Linux |
- cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* Versions before 6.6.24; 6.7 to before 6.7.12 Vulnerable ·Linux
- cpe:2.3:o:linux:linux_kernel:6.8:rc1:*:*:*:*:*:* Versions 6.8 rc1 Vulnerable ·Linux
- cpe:2.3:o:linux:linux_kernel:6.8:rc2:*:*:*:*:*:* Versions 6.8 rc2 Vulnerable ·Linux
- cpe:2.3:o:linux:linux_kernel:6.8:rc3:*:*:*:*:*:* Versions 6.8 rc3 Vulnerable ·Linux
- cpe:2.3:o:linux:linux_kernel:6.8:rc4:*:*:*:*:*:* Versions 6.8 rc4 Vulnerable ·Linux
- cpe:2.3:o:linux:linux_kernel:6.8:rc5:*:*:*:*:*:* Versions 6.8 rc5 Vulnerable ·Linux
Remediation
- Fix · CNA Linux (Linux) Fixed in 6.1.191, 6.6.24, 6.7.12, 6.8
Vendor assessments
Red Hat
Red Hat rating: Moderate. Red Hat's page for this CVE →
| Product | Status | Plan or fix |
|---|---|---|
| Red Hat Enterprise Linux 6 | Affected | No fix planned: Out of support scope |
| Red Hat Enterprise Linux 7 | Affected | No fix planned: Out of support scope |
Not affected: 2 products
- Red Hat Enterprise Linux 8
- Red Hat Enterprise Linux 9
Timeline
- 2026-10-02 Threatist record created from CVE-2024-35784
- 2026-10-03 Alias added: GHSA-hg9c-4q92-whw7
- 2026-10-30 Fix available: Linux/Linux@06d3879bb51be205a04b3da752cfd121a3367fb1, Linux/[email protected] · CNA
- 2026-10-30 1 new reference · CNA
References
Patch 3
More Linux Kernel vulnerabilities
- TI-2025-26358 tls: fix handling of zero-length records on the rx_list KEVCVSS 3.1CRITICAL 9.8
- TI-2026-38352 netfilter: bridge: make ebt_snat ARP rewrite writable KEVCVSS 3.1HIGH 8.8
- TI-2013-05264 The (1) get_user and (2) put_user API functions in the Linux kernel before 3.5.5 on the… KEVCVSS 3.1HIGH 8.8
- TI-2022-00125 Integer overflow in kernel KEVCVSS 3.1HIGH 8.4
- TI-2013-01864 The perf_swevent_init function in kernel/events/core.c in the Linux kernel before 3.8.9… KEVCVSS 3.1HIGH 8.4
- TI-2021-05514 Heap Out-Of-Bounds Write in Netfilter IP6T_SO_SET_REPLACE KEVCVSS 3.1HIGH 8.3
Sources
- CVE-2024-35784 · CVE Program
- CVE-2024-35784 · NVD
- FIRST EPSS
- GHSA-hg9c-4q92-whw7 · GitHub Advisory Database · CC BY 4.0
- CVE-2024-35784 · Red Hat security data · CC BY 4.0
This product uses the NVD API but is not endorsed or certified by the NVD. Sources and licences