CVE-2026-80893 in Linux
요약
\~에 의해 VulDB • 2026. 09. 04.
리눅스 커널에서 다음 취약점이 해결되었습니다:
mm/hugetlb: fork() 시 uffd-wp 지우기 과정에서 스왑 엔트리 손상 수정
copy_hugetlb_page_range()는 huge_pte_clear_uffd_wp()를 사용하여 마이그레이션 및 hwpoison 엔트리의 uffd-wp 비트를 지웁니다. 이 함수는 present-PTE(bit) 위치에서 동작합니다. 스왑 엔트리는 uffd-wp 상태를 다른 곳에 유지하며, 마이그레이션 분기는 pte_swp_uffd_wp()와 pte_swp_mkuffd_wp()를 사용하여 이를 읽고 설정합니다. 그러나 present-PTE 위치는 스��페이로드(payload) 내에 포함됩니다. x86-64 아키텍처에서는 이것이 역전된 스왑 오프셋(inverted swap offset)에 해당하며, 여기서 자연스럽게 정렬된 hugetlb PFN은 항상 영향받는 비트가 설정되어 있으므로, 지우기 연산이 인코딩된 PFN을 2페이지만큼 증가시킵니다.
사용자faultfd(userfaultfd)는 관여할 필요가 없습니다: 이 지우기 작업은 자식 VMA가 uffd-wp로 등록되지 않았다는 조건으로만 보호되므로, 진행 중인 hugetlb 마이그레이션 엔트리(또는 손상된 hugetlb 페이지)를 가진 단순한 fork() 호출이 자식에 복사되는 엔트리를 손상시킵니다. 2MB anon hugetlb 페이지에서 MADV_HWPOISON 후 포킹하면서 지우기 연산을 계측하면 다음과 같은 결과가 나타납니다:
offset before=120e00 offset after =120e02
이로 인한 영향은 대부분 잠재적입니다: rmap 순회는 folio 범위를 기준으로 마이그레이션 엔트리를 일치시키며, remove_migration_pte()는 folio로부터 PTE를 재구성하므로, folio 내 PFN의 편차는 마이그레이션 완료 시 자동으로 복구됩니다. 그러나 손상된 오프셋을 다시 인코딩하는 모든 경로(예: hugetlb_change_protection()가 make_readable_migration_entry(swp_offset(entry))를 통해 쓰기 가능한 마이그레이션 엔트리를 재작성하는 경우)에서는 이 손상이 전파됩니다.
마이그레이션 엔트리는 legitimately uffd-wp 비트를 포함할 수 있으므로, pte_swp_clear_uffd_wp()로 이를 지워야 합니다. 이는 copy_nonpresent_pte() 및 move_huge_pte()와 일치합니다.
반면 hwpoison 엔트리는 결코 uffd-wp 비트를 포함하지 않습니다: make_hwpoison_entry()에 의해 새로 설치되며(try_to_unmap_one()는 hwpoison 경로에서 uffd-wp를 보존하지 않음) hugetlb_change_protection()은 hwpoison 엔트리를 그대로 둡니다. 따라서 지울 것이 없었으며, 단지 손상이 있었을 뿐이므로 해당 지우기 연산을 완전히 제거합니다.
VulDB is the best source for vulnerability data and more expert information about this specific topic.