CVE-2026-89759 in Linux
요약
\~에 의해 VulDB • 2026. 09. 12.
리눅스 커널에서 다음 취약점이 해결되었습니다:
mm/kmemleak: 태스크 스택 스캔 시 소프트 락업 방지
패치 시리즈 "mm/kmemleak: scanning task 동안 soft lockup 방지", v3 버전.
kmemleak_scan() 함수는 하나의 rcu_read_lock() 컨텍스트 내에서 모든 태스크의 스택을 스캔하며, 이 과정에서 reschedule 지점이 없어 매우 많은 스레드를 가진 호스트에서 소프트 락업 감시 프로그램(soft lockup watchdog)이 트리거될 수 있습니다.
이는 워크로드와 호스트 구성에 따라 다음과 같은 메시지를 출력합니다:
watchdog: BUG: soft lockup - CPU#35 stuck for 22s! [kmemleak:537]
scan_block kmemleak_scan kmemleak_scan_thread kthread
패치 1은 find_ge_pid()를 사용하여 태스크들을 순회하므로, 스캔이 태크 간에 reschedule됩니다.
패치 2-3은 스캔이 중단된 경우 조기에 스캔 루프를 종료하도록 합니다.
다음 패치(총 3개 중):
kmemleak_scan() 함수는 모든 스레드를 순회하며 단일 rcu_read_lock() 하에서 각자의 커널 스택을 스캔합니다. 이 과정에는 reschedule 지점이 없습니다. 매우 많은 스레드가 있는 호스트에서는 -- 디버그 빌드 시 KASAN/lockdep에 의해 증폭되어 -- 이 루프가 CPU를 장시간 점유하여 소프트 락업 감시 프로그램을 트리거할 수 있습니다:
watchdog: BUG: soft lockup - CPU#35 stuck for 22s! [kmemleak:537]
scan_block kmemleak_scan kmemleak_scan_thread kthread
cond_resched()를 직접 추가할 수 없습니다. 해당 루프는 RCU 읽기 측 임계 섹션(RCU read-side critical section) 내부에서 실행되기 때문입니다.
find_ge_pid()를 사용하여 태스크들을 PID 단위로 순회하며, 각 태스크를 조회하고 고정(pinning)하기 위해만 RCU 읽기 잠금을 사용합니다. 그런 다음 스택은 잠금이 해제된 상태에서 스캔되므로, cond_resched()가 태크 간에 실행되고 scan_should_stop()이 true일 경우 조기에 스캔이 중단됩니다. 이는 next_tgid()/task_seq_get_next()의 반복 패턴을 따르며 각 RCU 임계 섹션을 짧게 유지합니다.
If you want to get best quality of vulnerability data, you may have to visit VulDB.