🇰🇷 한글 설명
리눅스 커널의 mm/migrate 구성 요소에서 shmem folio의 xarray 업데이트 과정 중 발생하는 취약점입니다. shmem이 swap cache에 있을 때와 page cache에 있을 때를 구분하지 못해 xarray 멀티 인덱스 엔트리가 손상될 수 있습니다. 이로 인해 메모리 관리 구조의 무결성이 깨질 위험이 있습니다.
💡 쉬운 설명
컴퓨터의 메모리를 관리하는 과정에서 데이터가 저장되는 위치를 잘못 판단하여 데이터 구조를 망가뜨리는 오류입니다. 이 오류로 인해 시스템이 불안정해지거나 예상치 못한 동작을 할 수 있습니다.
🇺🇸 원문 (English)
In the Linux kernel, the following vulnerability has been resolved:
mm/migrate: fix shmem xarray update during migration
A shmem folio can be either in page cache or in swap cache, but not at the
same time. Namely, once it is in swap cache, folio->mapping should be
NULL, and the folio is no longer in a shmem mapping.
In __folio_migrate_mapping(), to determine the number of xarray entries to
update, folio_test_swapbacked() is used, but that conflates shmem in page
cache case and shmem in swap cache case. It leads to xarray multi-index
entry corruption, since it turns a sibling entry to a normal entry during
xas_store() (see [1] for a userspace reproduction). Fix it by only using
folio_test_swapcache() to determine whether xarray is storing swap cache
entries or not to choose the right number of xarray entries to update.
[1] https://lore.kernel.org/linux-mm/
[email protected]/
Note:
In __split_huge_page(), folio_test_anon() && folio_test_swapcache() is
used to get swap_cache address space, but that ignores the shmem folio in
swap cache case. It could lead to NULL pointer dereferencing when a
in-swap-cache shmem folio is split at __xa_store(), since
!folio_test_anon() is true and folio->mapping is NULL. But fortunately,
its caller split_huge_page_to_list_to_order() bails out early with EBUSY
when folio->mapping is NULL. So no need to take care of it here.
📍 영향받는 시스템
Linux Kernel (shmem 및 xarray 관련 모듈을 사용하는 버전)
⚔️ 공격 벡터
메모리 마이그레이션 과정에서 특정 조건의 shmem folio를 조작하여 xarray 엔트리 손상을 유도
🛡️ 대응 방법
리눅스 커널을 최신 보안 패치가 적용된 버전으로 업데이트하여 mm/migrate 관련 수정 사항 반영
🔧 검증 코드
출력된 커널 버전을 확인하여 해당 취약점이 해결된 패치 버전인지 확인