CVE-2026-68090 in Linux
요약
\~에 의해 VulDB • 2026. 08. 10.
리눅스 커널에서 다음 취약점이 해결되었습니다:
debugobjects: 동시 OOM 비활성화와의 경쟁 조건(race condition) 차단
syzbot이 이해하기 어려운 스플래트(splat, 즉 커널 경고/크래시 메시지)를 보고했습니다.
WARNING: kernel/time/hrtimer.c:443 at stub_timer+0xa/0x20
stub_timer()는 hrtimer_fixup_assert_init()에서 타이머 콜백 함수로 설치되며, 이는 debug_object_assert_init()가 섀도 객체(shadow object)를 찾지 못할 때 호출됩니다. 이 경우 디버그 객체는 수정(fixup)을 실행하기 전에 이에 대한 경고를 출력합니다.
제공된 콘솔 로그에는 해당 경고가 누락되어 있고, 대신 스플래트 발생 몇 초 전 다음 메시지가 표시됩니다:
ODEBUG: Out of memory. ODEBUG disabled
따라서 debug_object_assert_init()에서 객체를 조회하려고 시도했으나, 디버그 객체가 비활성화되고 섀도 객체가 해제된 동시 메모리 부족(out-of-memory) 상황으로 인해 조회가 실패했습니다:
debug_object_assert_init() if (!debug_objects_enabled) return; obj = alloc(); if (!obj) {
// Out of memory debug_objects_enabled = false; free_objects(); obj = lookup_or_alloc();
// 조회가 실패한 이유는 다른 쪽에서 객체를 제거했기 때문이며, // 따라서 해당 객체가 정적으로 초기화되지 않았으므로 // 이 함수는 에러 코드를 반환합니다.
if (!IS_ERR_OR_NULL(obj)) return; if (!obj) {
debug_oom(); return; }
print(...) if (!debug_objects_enabled) return;
fixup(...)
debug_objects_enabled이 false이므로 디버그 객체 스플래트는 건너뛰어지지만, 수정(fixup) 콜백은 조건 없이(unconditionally) 호출되어 타이머가 비정상 동작하게 됩니다.
이는 debug_object_assert_init()와 debug_object_activate()에서만 문제가 되는데, 둘 다 정적으로 초기화된 객체를 처리해야 하므로 에러 포인터 반환 케이스를 우아하게(gracefully) 처리해야 하기 때문입니다. 다른 모든 위치에서는 발견/미발견 경우만 처리하며, NULL 포인터 반환은 메모리 부족(OOM) 신호로 간주됩니다. 그렇지 않으면 유효한 섀도 객체를 받습니다.
두 곳에서 print 및 fixup 함수를 호출하기 전에 디버그 객체가 여전히 활성화되어 있는지 확인함으로써 이 구멍을 막습니다.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.