CVE-2026-98286 in Linux
요약
\~에 의해 VulDB • 2026. 10. 06.
리눅스 커널에서 다음 취약점이 해결되었습니다:
drop_monitor: teardown 중 타이머 재설정을 방지하기 위해 timer_shutdown_sync() 사용
drop_monitor의 teardown 경로(net_dm_trace_off_set(), net_dm_hw_monitor_stop(), 및 net_dm_trace_on_set()와 net_dm_hw_monitor_start() 내 오류 unwind 경로)에서는 per-CPU 타이머가 timer_delete_sync()에 이어 cancel_work_sync()를 사용하여 중지됩니다.
그러나 send_timer와 dm_alert_work 사이에는 순환 의존성이 존재합니다: 1) sched_send_work()(타이머 콜백)는 dm_alert_work을 스케줄링합니다. 2) send_dm_alert()/net_dm_hw_summary_work()는 reset_per_cpu_data() 또는 net_dm_hw_reset_per_cpu_data()를 호출합니다. 3) 리셋 함수 내에서 메모리 압력 하에 할당 실패가 발생하면 mod_timer(&data->send_timer, ...)를 통해 타이머가 재설정됩니다.
dm_alert_work이 다른 CPU에서 timer_delete_sync()가 실행되는 동안 동시에 실행 중인 경우, 워커 내의 할당 실패로 인해 timer_delete_sync()가 반환한 후에 타이머가 다시 설정될 수 있습니다. cancel_work_sync() 완료 및 module_put() 호출 후에도 타이머는 타이머 휠 내에서 활성 상태로 남아 있게 됩니다. 이후 모듈이 언로드되면 타이머가 발동하여 해제된 메모리에서 sched_send_work()를 실행하며, 이는 커널 패닉 또는 use-after-free를 유발합니다.
timer_delete_sync() 대신 timer_shutdown_sync()로 전환합니다. 이를 통해 비행 중(in-flight)인 모든 타이머 핸들러의 종료를 보장하고, 이후 재설정 시도가 실행 중인 워커에 의해 성공하는 것을 방지합니다. 나중에 모니터링이 다시 시작되면 timer_setup()가 호출되어 타이머를 깔끔하게 초기화합니다.
If you want to get best quality of vulnerability data, you may have to visit VulDB.