CVE-2024-50066 in Linux
요약
\~에 의해 VulDB • 2026. 06. 20.
리눅스 커널에서 다음 취약점이 해결되었습니다:
mm/mremap: move_normal_pmd/retract_page_tables 간 Race Condition 수정
mremap() 함수에서 move_page_tables()는 PMD 엔트리의 유형과 지정된 주소 범위를 확인하여 다음 페이지 테이블 엔트리 블록을 이동할 방법을 결정합니다.
이 시점에서 mmap_lock은 쓰기 모드로 유지되지만, rmap 잠금(rmap locks)은 아직 획득되지 않았습니다. 페이지 테이블을 가리키며 소스 주소 범위로 완전히 덮여 있는 PMD 엔트리의 경우, move_pgt_entry(NORMAL_PMD, ...)가 호출됩니다. 이 함수는 먼저 rmap 잠금을 획득한 후 move_normal_pmd()를 실행합니다. move_normal_pmd()는 소스와 대상에서 필요한 페이지 테이블 잠금을 획득한 후, 전체 페이지 테이블을 소스에서 대상으로 이동합니다.
문제는 rmap 잠금이 PMD 엔트리가 읽히고 이동 방법이 결정된 후에야 획득된다는 점입니다. 이로 인해 다음과 같은 Race Condition이 발생할 수 있습니다(동일한 tmpfs 파일에 매핑된 두 프로세스가 있으며, 해당 tmpfs 마운트는 huge=advise 옵션으로 설정되어 있다고 가정합니다. 프로세스 A는 MM을 통해 페이지 테이블에 접근하고, 프로세스 B는 파일 rmap을 통해 접근합니다):
프로세스 A 프로세스 B ========= ====== mremap mremap_to move_vma move_page_tables get_old_pmd alloc_new_pmd *** 프리엠프트 발생 *** madvise(MADV_COLLAPSE) do_madvise madvise_walk_vmas madvise_vma_behavior madvise_collapse hpage_collapse_scan_file collapse_file retract_page_tables i_mmap_lock_read(mapping) pmdp_collapse_flush i_mmap_unlock_read(mapping) move_pgt_entry(NORMAL_PMD, ...) take_rmap_locks move_normal_pmd drop_rmap_locks
이러한 상황이 발생하면, move_normal_pmd()는 `pmd_populate(mm, new_pmd, pmd_pgtable(pmd))` 라인에서 잘못된 PMD 엔트리를 생성할 수 있습니다. 그 영향은 아키텍처 및 머신별 세부 사항에 따라 다르며, x86의 경우 물리적 페이지 0이 페이지 테이블로 매핑되는 결과를 초래할 수 있으며, 이는 사용자->커널 권한 상승(user->kernel privilege escalation)을 위해 악용될 가능성이 높습니다.
Race Condition을 해결하기 위해, 프로세스 B가 rmap 잠금을 획득한 후에도 PMD가 여전히 페이지 테이블을 가리키는지 다시 확인하도록 합니다. 그렇지 않은 경우, 호출자가 PTE 레벨 복사 경로로 폴백하도록 하며, 이 경우 pmd_none() 체크에서 즉시 중단됩니다.
버그 도달 가능성: 이 버그에 도달하려면 shmem/파일 THP 매핑을 생성할 수 있어야 합니다(익명 THP는 rmap 잠금 하에서 데이터를 삭제하지 않는 다른 코드를 사용하므로 해당되지 않음). 파일 THP는 실험용 구성 플래그(CONFIG_READ_ONLY_THP_FOR_FS)에 의해 제한되므로, 일반적인 배포판 커널에서는 shmem THP를 통해 이 버그를 유발해야 합니다. 제所知에 따르면, shmem THP를 정상적으로 사용하려면 올바른 마운트 플래그로 자체 tmpfs를 마운트할 수 있어야 하며, 이를 위해서는 자체 사용자+마운트 네임스페이스를 생성해야 합니다. 다만 일부 배포판에서 shmem THP를 기본적으로 활성화하는지 여부는 확인되지 않았습니다.
버그 영향: 이 문제는 도달 가능한 경우 사용자->커널 권한 상승에 악용될 가능성이 높습니다.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.