🇰🇷 한글 설명
리눅스 커널의 메모리 관리(mm) 서브시스템에서 deferred split 스캔과 대형 폴리오(large folio) 마이그레이션 간의 경쟁 상태(race condition)로 인해 발생하는 취약점입니다. 이로 인해 메모리 상태 오류, 시스템 충돌(crash), 또는 이중 해제(double free)와 같은 심각한 커널 오류가 발생할 수 있습니다.
💡 쉬운 설명
컴퓨터의 메모리를 관리하는 과정에서 두 가지 작업이 동시에 일어나 충돌이 발생하는 문제입니다. 이 충돌로 인해 컴퓨터 시스템이 갑자기 멈추거나 오류가 발생할 수 있습니다.
🇺🇸 원문 (English)
In the Linux kernel, the following vulnerability has been resolved:
mm: fix crashes from deferred split racing folio migration
Even on 6.10-rc6, I've been seeing elusive "Bad page state"s (often on
flags when freeing, yet the flags shown are not bad: PG_locked had been
set and cleared??), and VM_BUG_ON_PAGE(page_ref_count(page) == 0)s from
deferred_split_scan()'s folio_put(), and a variety of other BUG and WARN
symptoms implying double free by deferred split and large folio migration.
6.7 commit 9bcef5973e31 ("mm: memcg: fix split queue list crash when large
folio migration") was right to fix the memcg-dependent locking broken in
85ce2c517ade ("memcontrol: only transfer the memcg data for migration"),
but missed a subtlety of deferred_split_scan(): it moves folios to its own
local list to work on them without split_queue_lock, during which time
folio->_deferred_list is not empty, but even the "right" lock does nothing
to secure the folio and the list it is on.
Fortunately, deferred_split_scan() is careful to use folio_try_get(): so
folio_migrate_mapping() can avoid the race by folio_undo_large_rmappable()
while the old folio's reference count is temporarily frozen to 0 - adding
such a freeze in the !mapping case too (originally, folio lock and
unmapping and no swap cache left an anon folio unreachable, so no freezing
was needed there: but the deferred split queue offers a way to reach it).
📍 영향받는 시스템
Linux kernel (6.10-rc6 및 이전 버전 중 취약한 버전)
⚔️ 공격 벡터
로컬 공격자가 메모리 관리 프로세스의 경쟁 상태를 유도하여 커널 오류를 발생시킴
🛡️ 대응 방법
리눅스 커널을 최신 보안 패치가 적용된 버전으로 업데이트
🔧 검증 코드
출력된 커널 버전이 취약점이 해결된 최신 패치 버전인지 확인