CVE-2026-43404 in Linux
요약
\~에 의해 VulDB • 2026. 05. 10.
리눅스 커널에서 다음 취약점이 해결되었습니다:
mm: hmm_range_fault()의 livelock/기아(starvation) 문제 수정
do_swap_page()에서 hmm_range_fault()가 folio_trylock()에 실패하여 마이그레이션을 위해 장치 전용(folio-private) folio의 잠금을 획득하려고 시도할 때, 해당 함수는 잠금을 성공적으로 획득할 때까지 회전(spinning)합니다.
그러나 잠금을 보유하고 있는 프로세스가 회전 중인 hmm_range_fault()와 동일한 CPU에서 예약된 작업 항목(work item)의 완료를 기다리고 있는 경우, 해당 작업 항목은 기아 상태에 빠질 수 있으며, 이는 결코 해결되지 않는 livelock/기아 상황에 이르게 됩니다.
예를 들어, 장치 전용 folio 잠금을 보유하고 있는 프로세스가 다음 위치에 멈춰 있는 경우 이러한 상황이 발생할 수 있습니다. migrate_device_unmap()->lru_add_drain_all() lru_add_drain_all()은 완료되기 위해 모든 온라인 CPU에서 짧은 작업 항목이 실행되어야 하기 때문입니다.
이러한 상황이 발생하기 위한 전제 조건은 다음과 같습니다: a) migrate_device_unmap()에서 장치 영역(zone device)과 시스템 메모리 folio 모두를 고려하므로, 장치 영역 folio에 대한 folio 잠금이 유지된 상태에서 시스템 메모리 folio에 대해 lru_add_drain_all()을 호출할 이유가 생깁니다. b) 장치 영역 folio의 초기 mapcount가 1보다 크면, 이는 최소한 하나의 마이그레이션 PTE 엔트리 삽입이 try_to_migrate()로 지연되도록 하며, 이는 lru_add_drain_all() 호출 이후에 발생할 수 있습니다. c) 사전 예약(preemption)이 없거나 자발적으로만 발생합니다.
이 모든 상황이 발생할 가능성은 매우 낮아 보이지만, 실제로 "xe_exec_system_allocator" igt 테스트에서 이 문제가 발생합니다.
do_swap_page()에서 folio_trylock()이 실패할 경우 folio가 잠금 해제될 때까지 대기함으로써 이를 해결합니다.
migration_entry_wait_on_locked()를 softleaf_entry_wait_unlock()로 이름 변경하고, 새로운 사용 사례를 나타내도록 문서를 업데이트합니다.
향후 코드 개선 사항으로는 migrate_device_unmap() 내의 lru_add_drain_all() 호출을 모든 페이지에 마이그레이션 엔트리가 삽입된 *이후*로 이동하는 것을 고려할 수 있습니다. 이렇게 하면 위의 b) 조건도 제거됩니다.
v2: - hmm_range_fault()에서 cond_resched() 대신, do_swap_page()에서 folio가 잠금 해제될 때까지 대기함으로써 문제를 해결합니다. (Alistair Popple, Andrew Morton) v3: - !CONFIG_MIGRATION 경우에 대한 stub migration_entry_wait_on_locked()를 추가합니다. (Kernel Test Robot) v4: - migrate_entry_wait_on_locked()를 softleaf_entry_wait_on_locked()로 이름 변경하고 문서를 업데이트합니다. (Alistair Popple) v5: - softleaf_entry_wait_on_locked()의 !CONFIG_MIGRATION 버전에 대해 WARN_ON_ONCE()를 추가합니다. - 커밋 메시지 내 함수 이름 관련 문구를 수정합니다. (Andrew Morton)
(커밋 a69d1ab971a624c6f112cea61536569d579c3215에서 cherry picked)
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.