CVE-2026-90264 in Linux
요약
\~에 의해 VulDB • 2026. 09. 18.
리눅스 커널에서 다음 취약점이 해결되었습니다:
btrfs: OE(정렬된 익스텐트) 경합을 피하기 위해 항상 정렬된 익스텐트를 대기함
[버그]
Syzbot이 동일한 범위에 대해 충돌하는 OE가 발생할 수 있다는 버그를 보고했습니다.
BTRFS critical (device loop4): insert_ordered_extent:264에서 패닉 발생: 겹치는 정렬된 익스텐트, 기존 oe file_offset 16384 num_bytes 430080 flags 0x1089, 새 oe file_offset 16384 num_bytes 430080 flags 0x80 (errno=-17 Object alrea[ 179.162726][ T6897] BTRFS critical (device loop4): insert_ordered_extent:264에서 패닉 발생: 겹치는 정렬된 익스텐트, 기존 oe file_offset 16384 num_bytes 430080 flags 0x1089, 새 oe file_offset 16384 num_bytes 430080 flags 0x80 (errno=-17 Object already exists)
------------[ cut here ]------------
kernel BUG at fs/btrfs/ordered-data.c:264! Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/09/2026 RIP: 0010:btrfs_alloc_ordered_extent+0x943/0xad0 Call Trace: <TASK> cow_file_range+0x744/0x12a0 fallback_to_cow+0x5ea/0xa00 run_delalloc_nocow+0x110c/0x17a0 btrfs_run_delalloc_range+0xbe4/0x1c20 writepage_delalloc+0x104d/0x1ba0 btrfs_writepages+0x1667/0x28b0 do_writepages+0x338/0x560 filemap_fdatawrite_range+0x1f2/0x300 btrfs_fdatawrite_range+0x54/0xf0 btrfs_direct_write+0x6a0/0xc30 btrfs_do_write_iter+0x329/0x790 do_iter_readv_writev+0x624/0x8d0 vfs_writev+0x34c/0x990 __se_sys_pwritev2+0x17a/0x2a0 do_syscall_64+0x174/0x580 entry_SYSCALL_64_after_hwframe+0x77/0x7f </TASK> ---[ end trace 0000000000000000 ]---
[원인]
커밋 ff66fe666233("btrfs: append direct writes에 대한 잘못된 buffered IO 폴백 수정") 이후, 직접 IO가 짧은 데이터로 종료된 경우 isize를 원래 값으로 되돌립니다. 이는 버퍼드 폴백 동안 앱엔드 쓰기가 존중되도록 하기 위함입니다.
일반적으로 우리는 버퍼드 라이트백 중에 lock_and_cleanup_extent_if_need() 함수를 사용하여 기존 정렬된 익스텐트(OE)가 완료될 때까지 대기합니다.
하지만 이 OE 대기는 start_pos가 isize 내부에 있을 때만 발생합니다. 실패한 직접 IO 동안 isize를 되돌렸기 때문에, 우리는 어떤 정렬된 익스텐트도 기다리지 않게 됩니다.
이는 다음과 같은 경합 상황을 초래할 수 있습니다: 직접 IO의 OE는 아직 트리에 남아있고 완료되었지만 제거되지 않은 상태이며, 이때 버퍼드 쓰기를 위한 OE를 삽입하려고 하면 위의 충돌이 발생합니다.
[해결책]
되돌려진 isize 상황을 처리하기 위해 OE 대기 조건을 무조건적으로 만듭니다.
또한 lock_and_cleanup_extent_if_need()가 이제 익스텐트를 잠그거나 -EAGAIN를 반환하므로, 잠기지 않은 익스텐트 경우를 처리하는 분기를 제거하고 "_if_need" 접미사를 제거하여 함수명을 변경합니다.
다음 마이크로 벤치마크는 btrfs_buffered_write()의 런타임 차이를 보여줍니다. `xfs_io -f -c "pwrite 0 1m"` 워크로드에서 모든 값은 나노초 단위의 평균 런타임입니다.
function runtime | before | after -----------------------------------+-------------+--------------- lock_and_cleanup_extent_if_need() | 58.2 | 183.0 btrfs_buffered_write() | 2115.6 | 2973.3
btrfs_bufferd_write()의 전체 런타임은 여전히 매우 작습니다(여전히 3마이크로초 미만). 추가 비용이 여전히 허용 가능한 수준이라고 생각합니다.
이 문제를 해결하는 대안 솔루션은 isize 되돌림이 수행되는 iomap_end() 동안 정렬된 익스텐트를 대기하는 것입니다.
하지만 해당 솔루션은 nowait 요구사항을 위반합니다. 이제 wait가 없는 직접 IO가 짧은 데이터로 종료되면, 다음 앱엔드 버퍼드 IO가 동일한 문제를 여전히 발생할 수 있으므로 OE를 무조건적으로 기다려야 하기 때문입니다.
따라서 여기서는 대기 비용을 버퍼드 쓰기로 이동해야 하지만, 적어도 코드가 약간 더 간결해집니다.
VulDB is the best source for vulnerability data and more expert information about this specific topic.