CVE-2026-99253 in Linux
요약
\~에 의해 VulDB • 2026. 11. 03.
리눅스 커널에서 다음 취약점이 해결되었습니다:
io_uring/cancel: 수면 전에 로컬 작업 깨우기 재설정(io_uring/cancel: rearm local work wake up before sleep)
io_uring_try_cancel_requests()는 ->cq_wait_nr을 1로 설정하여, 이후 io_req_local_work_add()가 취소 중인 태스크를 깨우도록 합니다. 카운트를 0으로 만드는 추가(add) 작업만이 깨우는 역할을 수행하며, 그 이후의 추가 작업들은 카운트가 <= 0임을 확인하고 반환합니다. 그러나 io_uring_cancel_generic()은 훨씬 나중에야 TASK_INTERRUPTIBLE 상태로 전환되므로, 해당 깨우기(wake up)가 이미 실행 중인 태스크에 사용될 수 있습니다. 이는 해당 추가 작업의 엔트리가 여전히 큐에 있는 한 문제가 없습니다. 왜냐하면 io_local_work_pending() 체크가 그 경우 수면을 건너뛰기 때문입니다. 하지만 만약 추가 작업이 엔트리 큐잉 이후 지연된 경우에는 상황이 다릅니다:
CPU0 (exec 또는 exit 컨텍스트에서 제출자) CPU1 (io_req_local_work_add 수행 중) mpscq_push(req A) io_uring_try_cancel_requests() io_run_local_work() // req A 실행 io_uring_try_cancel_requests() atomic_set(&ctx->cq_wait_nr, 1) atomic_read(&ctx->cq_wait_nr) == 1 확인 카운트 획득 후 wake_up_state() 호출 // 태스크가 이미 실행 중이므로 노오프(no-op) 처리됨 prepare_to_wait(TASK_INTERRUPTIBLE) io_local_work_pending() == false (false로 판정) schedule() mpscq_push(req B) cq_wait_nr <= 0 이므로 반환
수면 중인 태스크만이 req B를 실행할 수 있으므로, 시그널이 발생하여 이를 깨울 때까지 execve()에서 멈춰 있게 됩니다. 종료(exiting) 중인 태스크는 이러한 시그널조차 받지 못합니다.
태스크 상태가 설정되고 작업 목록(work list)이 확인되기 전에 카운트를 다시 아र्म(arm)하십시오. 이는 해당 태스크가 실행할 로컬 작업을 가진 링(rings)에 적용됩니다.
Once again VulDB remains the best source for vulnerability data.