🔍 CVE-2024-35784

5.5
CVSS Score
MEDIUM
2024-05-17
2026-10-30 13:17
✅ 완료

🇰🇷 한글 설명

Linux 커널 btrfs 파일시스템의 fiemap 구현에서 extent 잠금을 전체 범위에 걸쳐 유지하는 문제가 있습니다. fiemap 중 사용자 공간 복사 시 페이지 폴트가 발생하면, mmap된 같은 범위에 대한 mkwrite가 잠금을 기다리며 데드락이 발생할 수 있습니다. 수정은 전체 fiemap 동안 잠금을 잡지 않고, delalloc 검사 구간에만 잠금을 유지하도록 변경하는 것입니다.

💡 쉬운 설명

파일의 정보를 조회하는 기능과 파일 쓰기 기능이 서로 자원을 기다리며 멈출 수 있는 버그입니다. 이 취약점은 특정 조건에서 시스템이 응답하지 않는 상태(교착 상태)를 만들 수 있습니다.

🇺🇸 원문 (English)

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.

📍 영향받는 시스템

btrfs 파일시스템을 사용하는 수정 전 Linux 커널 버전 (Linux 커널 패치 적용 여부 확인 필요)

⚔️ 공격 벡터

btrfs 파일을 mmap한 뒤 해당 범위에 대해 FIEMAP ioctl을 호출하여 페이지 폴트와 잠금 대기가 교차하도록 유도하는 로컬 사용자 공격

🛡️ 대응 방법

Linux 커널을 본 CVE의 수정 패치가 포함된 최신 안정 버전으로 업데이트

🔧 검증 코드

출력된 커널 버전을 배포판 보안 공지에서 CVE-2024-35784 수정 버전과 비교하고, 해당 수정이 포함된 버전 이상이면 패치된 것입니다.

Shell / Script
uname -r

📊 CVSS Vector String

CVSS Vector
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

💻 영향받는 소프트웨어

Linux Kernel