🇰🇷 한글 설명
Linux 커널의 ptdump 과정에서 init_mm의 mmap 락을 적절히 획득하지 않아 발생하는 레이스 컨디션 취약점입니다. x86 및 arm64 아키텍처에서 커널 페이지 테이블 해제 시점과 ptdump 작업이 충돌하여 시스템 불안정성을 초래할 수 있습니다.
💡 쉬운 설명
컴퓨터의 메모리 지도를 그리는 작업과 메모리를 정리하는 작업이 동시에 일어나면서 충돌이 발생하는 문제입니다. 이로 인해 시스템이 갑자기 멈추거나 오류가 발생할 수 있습니다.
🇺🇸 원문 (English)
In the Linux kernel, the following vulnerability has been resolved:
mm/ptdump: always stabilise against page table freeing using init_mm
Previous commits have established the invariant that kernel page table
freeing is performed while an mmap read lock on init_mm is held, which
fixes races between ptdump and kernel page table freeing over init_mm.
However, x86 and arm64 can perform a ptdump over an mm other than init_mm
via ptdump_walk_pgd() and since kernel memory ranges are shared across
non-kernel mm's, this means that the race still exists for these cases.
Fix this by acquiring a nested mmap write lock for init_mm in
ptdump_walk_pgd().
This is safe as we take this after mmap write locking the mm, and nothing
acquires the init_mm lock first before locking an arbitrary mm, so no
deadlock is possible.
Also update walk_page_range_debug() to assert that init_mm is write
locked, add a comment explaining why and remove some redundant code, and
eliminate the unnecessary and confusing invocation of
walk_kernel_page_table_range().
We can safely remove the non-NULL check for walk.mm, as the mmap lock
asserts would NULL pointer deref if it was (and of course no callers do
this).
The first point at which ptdump can race kernel page table freeing is
commit b6bdb7517c3d ("mm/vmalloc: add interfaces to free unmapped page
table"), so we target this in the Fixes tag.
📍 영향받는 시스템
Linux Kernel (x86, arm64 아키텍처 기반 시스템)
⚔️ 공격 벡터
특정 메모리 관리 작업이 동시에 수행되도록 유도하는 레이스 컨디션 공격
🛡️ 대응 방법
커널 패치를 적용하여 ptdump_walk_pgd() 호출 시 init_mm에 대한 중첩 mmap 쓰기 락을 획득하도록 업데이트
🔧 검증 코드
출력된 커널 버전이 해당 취약점이 수정된 최신 패치 버전인지 확인