CVE-2026-64416 in Linux
요약
\~에 의해 VulDB • 2026. 07. 25.
리눅스 커널에서 다음 취약점이 해결되었습니다:
mm: swap_cgroup: swapless 호스트에서 lookup_swap_cgroup_id()의 NULL 디레퍼런스 수정
lookup_swap_cgroup_id()는 swap_cgroup_swapon()을 통해 해당 타입이 등록되었는지 확인하지 않은 채로 swap_cgroup_ctrl[type].map를 __swap_cgroup_id_lookup()에 전달합니다. Swapless 호스트에서는 모든 ctrl->map가 NULL이므로, __swap_cgroup_id_lookup()은 NULL + 스케일된 swp_offset()을 디레퍼런스하게 됩니다.
커밋 bea67dcc5eea("mm: attempt to batch free swap entries for zap_pte_range()") 이후로, zap_pte_range() -> swap_pte_batch()는 swap_info[]에 대해 먼저 유효성을 검증하지 않고도 실제 스왑 엔트리로 디코딩되는 모든 비존재(non-present), 비-널(None) PTE에서 lookup_swap_cgroup_id()를 호출합니다. 타입 0(type-0) 스왑 엔트로 변조된 단일 PTE는 프로세스 종료 시 호스트를 다운시킵니다.
우리는 swapless 환경의 6.12.58 버전 호스트에서 실제 운영 중 이 문제를 겪었습니다: ~1초 동안 "get_swap_device: Bad swap file entry 3f800204222bb"(do_swap_page()가 해당 엔트리에 대해 올바르게 방어적 처리를 수행) 메시지가 출력된 후, 다음과 같은 오류가 발생했습니다.
BUG: unable to handle page fault for address: 000003f800204220 RIP: 0010:lookup_swap_cgroup_id+0x2b/0x60 Call Trace: swap_pte_batch+0xbf/0x230 zap_pte_range+0x4c8/0x780 unmap_page_range+0x190/0x3e0 exit_mmap+0xd9/0x3c0 do_exit+0x20c/0x4b0
syzbot도 동일한 스택을 보고했습니다.
PTE 변조의 원인은 별개의 버그이며, 이번 변경은 이미 fault 경로만큼 견고한 teardown 경로를 만듭니다. lookup_swap_cgroup_id()의 다른 모든 호출자는 get_swap_device() 이후에 위치하며, 해당 엔트리는 이미 유효성이 검증되었으므로 새로운 분기(branch)는 cold 상태가 됩니다.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.