CVE-2026-72043 in Linux
요약
\~에 의해 VulDB • 2026. 08. 16.
Linux 커널에서 다음 취약점이 해결되었습니다:
LoongArch: {pte,pmd}_wrprotect()에서의 더티 페이지 추적 누락 수정
LoongArch에서 하드웨어 페이지 테이블 워커(PTW)가 활성화되면, CPU는 쓰기 TLB 미스 발생 시 소프트웨어 TLB 스토어 핸들러를 거치지 않고 페이지 테이블 엔트리(PTE)에 _PAGE_DIRTY 비트를 직접 설정할 수 있습니다. 소프트웨어 TLB 스토어 핸들러(tlbex.S:254)에서는 _PAGE_DIRTY와 _PAGE_MODIFIED를 함께 설정합니다:
ori t0, t0, (_PAGE_VALID | _PAGE_DIRTY | _PAGE_MODIFIED)
하드웨어 PTW는 _PAGE_DIRTY만 설정하므로, 소프트웨어 전용 비트인 _PAGE_MODIFIED는 변경되지 않은 상태로 남습니다. 이로 인해 PTE에 _PAGE_DIRTY가 설정되어 있지만(하드웨어는 페이지가 더티임을 인지함), _PAGE_MODIFIED는 클리어된 상태(소프트웨어는 이를 미인지)라는 상황이 발생할 수 있습니다.
fork()/clone()이 copy-on-write(COW)를 트리거하면, __copy_present_ptes()에서 pte_wrprotect()를 호출하여 무조건적으로 _PAGE_WRITE 및 _PAGE_DIRTY 비트를 모두 클리어합니다:
pte_val(pte) &= ~(_PAGE_WRITE | _PAGE_DIRTY);
_PAGE_MODIFIED가 설정되지 않았으므로 더티 정보(dirtiness information)가 완전히 손실됩니다. 이후 메모리 압력이 페이지 리클레임을 트리거하면, page_mkclean() / try_to_unmap()는 해당 페이지를 클린(clean)으로 간주합니다(즉, pte_dirty()가 false를 반환함). 이로 인해 라이트백(writeback) 없이 페이지가 해제되어 데이터 손상(data corruption)이 발생할 수 있습니다.
이를 해결하기 위해 쓰기 가능 비트(writeable bits)를 클리어하기 전에 pte_wrprotect()와 pmd_wrprotect() 모두에서 _PAGE_DIRTY 비트를 _PAGE_MODIFIED 비트로 전파합니다:
if (pte_val(pte) & _PAGE_DIRTY) pte_val(pte) |= _PAGE_MODIFIED;
pmd_wrprotect() 수정은 CONFIG_TRANSPARENT_HUGEPAGE 경우를 처리하며, 이 경우 PMD 엔트리에도 동일한 조치가 필요합니다.
이를 통해 fork COW 쓰기 보호(write-protection) 동안 소프트웨어 더티 추적 비트(pte_dirty() 및 pmd_dirty()에서 참조되며, 이들은 _PAGE_DIRTY와 _PAGE_MODIFIED 비트 모두를 읽음)가 보존됩니다.
이 문제는 사설 익명 매핑(private anonymous mappings) 상의 "madvise(MADV_FREE), 쓰기 및 fork" 작업 시퀀스 이후 페이지 리클레임을 수행하는 LTP madvise09 테스트 케이스에 의해 발견되었습니다.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.