CVE-2026-98260 in Linux
Sumário
de VulDB • 06/10/2026
No kernel Linux, a seguinte vulnerabilidade foi resolvida:
exec: Limpeza dos timers POSIX logo após o de_thread()
Um timer de CPU por thread mantém uma referência ao PID da thread à qual está associado e, enquanto estiver armado, seu nó é enfileirado nos posix_cputimers dessa thread. A tarefa é procurada por esse PID.
Quando uma thread não líder executa a operação exec(), o de_thread() altera qual tarefa possui aquele PID. O pid_task(timer->it.cpu.pid, PIDTYPE_PID) retorna NULL, mas o nó ainda está enfileirado em tsk, que permanece vivo. A função timer_lock_sighand() interpreta um lookup falho como indicação de que o nó já foi desenfileirado, portanto não há nada a reverter.
O begin_new_exec() chama posix_cpu_timers_exit(me) logo após exec_task_namespaces(), removendo assim o nó residual; por isso, o estado normalmente permanece invisível. No entanto, bprm->point_of_no_return é definido antes do de_thread(); caso unshare_files(), set_mm_exe_file(), exec_mmap() ou exec_task_namespaces() falhem, a tarefa morre antes de chegar àquela etapa. O exit_itimers() então libera o k_itimer enquanto seu nó ainda está enfileirado, e o reaproveitamento posterior da tsk apaga esse nó já liberado do rbtree.
Em resumo:
thread não líder B pai timer_create(CLOCK_THREAD_CPUTIME_ID) timer_settime() arm_timer() // o nó é enfileirado em B execve() de_thread(B) exchange_tids(B, leader) // o PID de B agora pertence ao líder release_task(leader) __exit_signal(leader) posix_cpu_timers_exit(leader) // limpa a fila do líder, não a de B __unhash_process(leader) // esse PID não tem mais tarefa associada exec_mmap() mmap_read_lock_killable(old_mm) kill(B, SIGKILL) // -EINTR get_signal() do_exit() exit_itimers() posix_timer_delete() posix_cpu_timer_del() posix_timer_unhash_and_free() // liberado enquanto ainda enfileirado wait4() release_task(B) posix_cpu_timers_exit(B) cleanup_timerqueue() timerqueue_del() // use-after-free
Mova a limpeza dos timers POSIX para logo após o de_thread(), antes que qualquer uma das condições de falha posteriores leve a tarefa ao do_exit().
[ tglx: Move a limpeza para logo após o de_thread() ]
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.