Goal Reached Thanks to every supporter — we hit 100%!

Goal: 1000 CNY · Raised: 1336 CNY

100%

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

AI Predicted 4.7 Difficulty: Easy EPSS 0.17% · P7

Possible ATT&CK Techniques 1AI

T1499 · Endpoint Denial of Service

Affected Version Matrix 8

VendorProductVersion RangeStatus
LinuxLinux1506fcc8189cdd4b95e06df7845a09f18b4526a6< ded566b4637f1b6b4c9ba74e7d0b8493e93f19cfaffected
1506fcc8189cdd4b95e06df7845a09f18b4526a6< 89bca7fe6382d61e88c67a0b0e7bce315986fb8baffected
1506fcc8189cdd4b95e06df7845a09f18b4526a6< b0ad381fa7690244802aed119b478b4bdafc31ddaffected
2.6.29affected
< 2.6.29unaffected
6.6.24≤ 6.6.*unaffected
6.7.12≤ 6.7.*unaffected
6.8≤ *unaffected
Get alerts for future matching vulnerabilitiesLog in to subscribe

I. Basic Information for CVE-2024-35784

Vulnerability Information

Have questions about the vulnerability? See if Shenlong's analysis helps!
View Shenlong Deep Dive ↗

Although we use advanced large model technology, its output may still contain inaccurate or outdated information.Shenlong tries to ensure data accuracy, but please verify and judge based on the actual situation.

Vulnerability Title
btrfs: fix deadlock with fiemap and extent locking
Source: CVE Program / CVE List V5
Vulnerability Description
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.
Source: CVE Program / CVE List V5
CVSS Information
N/A
Source: CVE Program / CVE List V5
Vulnerability Type
N/A
Source: CVE Program / CVE List V5
Vulnerability Title
Linux kernel 安全漏洞
Source: CNNVD (China National Vulnerability Database)
Vulnerability Description
Linux kernel是美国Linux基金会的开源操作系统Linux所使用的内核。 Linux kernel存在安全漏洞,该漏洞源于存在死锁问题。
Source: CNNVD (China National Vulnerability Database)
CVSS Information
N/A
Source: CNNVD (China National Vulnerability Database)
Vulnerability Type
N/A
Source: CNNVD (China National Vulnerability Database)

Affected Products

VendorProductAffected VersionsCPESubscribe
LinuxLinux 1506fcc8189cdd4b95e06df7845a09f18b4526a6 ~ ded566b4637f1b6b4c9ba74e7d0b8493e93f19cf -
LinuxLinux 2.6.29 -

II. Public POCs for CVE-2024-35784

#POC DescriptionSource LinkShenlong Link
AI-Generated POCPremium

No public POC found.

Login to generate AI POC

III. Intelligence Information for CVE-2024-35784

登录查看更多情报信息。

Other References for CVE-2024-35784 (3)

Same Patch Batch · Linux · 2024-05-17 · 135 CVEs total

CVE-2023-526879.8 CRITICALcrypto: safexcel - Add error handling for dma_map_sg() calls
CVE-2024-358568.8 HIGHBluetooth: btusb: mediatek: Fix double free of skb in coredump
CVE-2024-358048.8 HIGHKVM: x86: Mark target gfn of emulated atomic instruction as dirty
CVE-2024-358438.8 HIGHiommu/vt-d: Use device rbtree in iopf reporting path
CVE-2024-358118.8 HIGHwifi: brcmfmac: Fix use-after-free bug in brcmf_cfg80211_detach
CVE-2024-274158.8 HIGHnetfilter: bridge: confirm multicast packets before passing them up the stack
CVE-2024-274168.8 HIGHBluetooth: hci_event: Fix handling of HCI_EV_IO_CAPA_REQUEST
CVE-2024-274048.2 HIGHmptcp: fix data races on remote_id
CVE-2023-526698.2 HIGHcrypto: s390/aes - Fix buffer overread in CTR mode
CVE-2024-358348.2 HIGHxsk: recycle buffer in case Rx queue was full
CVE-2024-357898.0 HIGHwifi: mac80211: check/clear fast rx for non-4addr sta VLAN changes
CVE-2024-358307.8 HIGHmedia: tc358743: register v4l2 async device only after successful setup
CVE-2024-358357.8 HIGHnet/mlx5e: fix a double-free in arfs_create_groups
CVE-2024-358277.8 HIGHio_uring/net: fix overflow check in io_recvmsg_mshot_prep()
CVE-2023-526627.8 HIGHdrm/vmwgfx: fix a memleak in vmw_gmrid_man_get_node
CVE-2024-358177.8 HIGHdrm/amdgpu: amdgpu_ttm_gart_bind set gtt bound flag
CVE-2024-358087.8 HIGHmd/dm-raid: don't call md_reap_sync_thread() directly
CVE-2024-357937.8 HIGHdebugfs: fix wait/cancellation handling during remove
CVE-2024-357987.8 HIGHbtrfs: fix race in read_extent_buffer_pages()
CVE-2024-358147.8 HIGHswiotlb: Fix double-allocation of slots due to broken alignment handling

Showing top 20 of 135 CVEs. View all on vendor page &rarr; →

IV. Related Vulnerabilities

V. Comments for CVE-2024-35784

No comments yet


Leave a comment