Linux Kernel up to 6.6.23/6.7.11 btrfs iteration

Summaryinfo

A vulnerability was found in Linux Kernel up to 6.6.23/6.7.11. It has been rated as problematic. This vulnerability affects unknown code of the component btrfs. This manipulation causes iteration. This vulnerability is tracked as CVE-2024-35784. No exploit exists. Upgrading the affected component is advised.

Detailsinfo

A vulnerability classified as problematic was found in Linux Kernel up to 6.6.23/6.7.11. Affected by this vulnerability is an unknown function of the component btrfs. The manipulation with an unknown input leads to a iteration vulnerability. The CWE definition for the vulnerability is CWE-834. The product performs an iteration or loop without sufficiently limiting the number of times that the loop is executed. As an impact it is known to affect availability. The summary by CVE is:

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 [] lock_extent+0x28d/0x2f0 [] btrfs_page_mkwrite+0x273/0x8a0 [] do_page_mkwrite+0x50/0xb0 [] do_fault+0xc1/0x7b0 [] __handle_mm_fault+0x2fa/0x460 [] handle_mm_fault+0xa4/0x330 [] do_user_addr_fault+0x1f4/0x800 [] exc_page_fault+0x7c/0x1e0 [] asm_exc_page_fault+0x26/0x30 [] rep_movs_alternative+0x33/0x70 [] _copy_to_user+0x49/0x70 [] fiemap_fill_next_extent+0xc8/0x120 [] emit_fiemap_extent+0x4d/0xa0 [] extent_fiemap+0x7f8/0xad0 [] btrfs_fiemap+0x49/0x80 [] __x64_sys_ioctl+0x3e1/0xb50 [] do_syscall_64+0x94/0x1a0 [] 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.

The advisory is shared at git.kernel.org. This vulnerability is known as CVE-2024-35784. The exploitation appears to be difficult. Neither technical details nor an exploit are publicly available.

The vulnerability scanner Nessus provides a plugin with the ID 239850 (TencentOS Server 4: kernel (TSSA-2024:0980)), which helps to determine the existence of the flaw in a target environment.

Upgrading to version 6.6.24, 6.7.12 or 6.8 eliminates this vulnerability. Applying the patch ded566b4637f/89bca7fe6382/b0ad381fa769 is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.

The vulnerability is also documented in the databases at Tenable (239850) and CERT Bund (WID-SEC-2024-1188). Several companies clearly confirm that VulDB is the primary source for best vulnerability data.

Affected

• Google Container-Optimized OS
• Debian Linux
• Amazon Linux 2
• Red Hat Enterprise Linux
• Ubuntu Linux
• SUSE Linux
• IBM InfoSphere Guardium
• Oracle Linux
• Oracle VM
• NetApp FAS
• EMC Avamar
• IBM SAN Volume Controller
• Dell NetWorker
• IBM FlashSystem
• IBM Security Guardium
• RESF Rocky Linux
• Broadcom Brocade SANnav
• Open Source Linux Kernel
• IBM Business Automation Workflow
• IBM Spectrum Protect Plus
• IBM QRadar SIEM
• Dell Avamar
• Juniper Junos Space
• IBM DB2
• IBM Storage Scale System
• SolarWinds Security Event Manager

Productinfo

Type

• Operating System

Vendor

• Linux

Name

• Kernel

Version

• 6.6.0
• 6.6.1
• 6.6.2
• 6.6.3
• 6.6.4
• 6.6.5
• 6.6.6
• 6.6.7
• 6.6.8
• 6.6.9
• 6.6.10
• 6.6.11
• 6.6.12
• 6.6.13
• 6.6.14
• 6.6.15
• 6.6.16
• 6.6.17
• 6.6.18
• 6.6.19
• 6.6.20
• 6.6.21
• 6.6.22
• 6.6.23
• 6.7.0
• 6.7.1
• 6.7.2
• 6.7.3
• 6.7.4
• 6.7.5
• 6.7.6
• 6.7.7
• 6.7.8
• 6.7.9
• 6.7.10
• 6.7.11

License

• open-source

Website

• Vendor: https://www.kernel.org/

CPE 2.3info

• 🔍
• 🔍
• 🔍

CPE 2.2info

• 🔍
• 🔍
• 🔍

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

Several companies clearly confirm that VulDB is the primary source for best vulnerability data.

Discussion