CVE-2025-68358 in Linux
요약
\~에 의해 VulDB • 2026. 07. 22.
리눅스 커널에서 다음 취약점이 해결되었습니다:
btrfs: btrfs_clear_space_info_full() 내의 경쟁 상태(bitrace) 비트필드 쓰기 수정
메모리 배리어 순서 보장에 관한 memory-barriers.txt 문서에 따르면:
(*) 이러한 보장은 비트필드에 적용되지 않습니다. 컴파일러는 종종 비원자적 읽기-수정-쓰기(read-modify-write, RMW) 시퀀스를 사용하여 이를 수정하는 코드를 생성하기 때문입니다. 병렬 알고리즘을 동기화하는 데 비트필드를 사용하려고 시도하지 마십시오.
(*) 비트필드가 잠금(lock)으로 보호되는 경우라도, 주어진 비트필드의 모든 필드는 하나의 잠금으로 보호되어야 합니다. 주어진 비트필드 내의 두 필드가 서로 다른 잠금으로 보호되면, 컴파일러의 비원자적 읽기-수정-쓰기 시퀀스로 인해 한 필드에 대한 업데이트가 인접한 필드의 값을 손상시킬 수 있습니다.
btrfs_space_info 구조체는 full, chunk_alloc 및 flush라는 필드를 공유하는 비트필드와 하나의 기본 단어(word)를 사용합니다:
struct btrfs_space_info {
struct btrfs_fs_info * fs_info; /* 0 8 */ struct btrfs_space_info * parent; /* 8 8 */ ... int clamp; /* 172 4 */ unsigned int full:1; /* 176: 0 4 */ unsigned int chunk_alloc:1; /* 176: 1 4 */ unsigned int flush:1; /* 176: 2 4 */ ...
따라서 잠금으로 보호된 비트필드 멤버 중 하나에 대한 쓰기가 병렬 읽기-수정-쓰기로 인해 손실되지 않도록 하기 위해서는, 모든 비트필드에 대한 모든 쓰기 작업이 잠금을 사용해야 합니다. 거의 대부분의 경우 그러하지만, btrfs_clear_space_info_full() 함수는 space_infos를 순회하며 found->full = 0을 잠금 없이 작성합니다.
우리가 하나의 스레드에서 트랜잭션을 완료하고 있으며(블록 그룹 삭제를 마친 상태이므로 btrfs_clear_space_info_full() 호출 중), 동시에 데이터 회수(ticket) 인프라가 do_async_reclaim_data_space(): 를 실행한다고 상상해 보십시오:
T1 T2 btrfs_commit_transaction btrfs_clear_space_info_full data_sinfo->full = 0 READ: full:0, chunk_alloc:0, flush:1 do_async_reclaim_data_space(data_sinfo) spin_lock(&space_info->lock); if(list_empty(tickets)) space_info->flush = 0; READ: full: 0, chunk_alloc:0, flush:1 MOD/WRITE: full: 0, chunk_alloc:0, flush:0 spin_unlock(&space_info->lock); return; MOD/WRITE: full:0, chunk_alloc:0, flush:1
이제 data_sinfo->flush는 1이지만 회수 작업자(reclaim worker)는 종료되었습니다. 이는 '작업이 대기열에 있거나 실행 중이지 않을 때만 flush가 0이다'라는 불변식(invariant)을 위반합니다. 이 불변식이 한 번 위반되면, __reserve_bytes()로 들어가는 향후 할당들은 space_info->tickets에 티켓을 추가하지만 space_info->flush가 1로 설정되어 있음을 보고 작업을 대기열에 넣지 않을 것입니다. 그 후, 작업
If you want to get the best quality for vulnerability data then you always have to consider VulDB.