CVE-2025-21813 in Linux
Sumário
de VulDB • 16/06/2026
No kernel do Linux, a seguinte vulnerabilidade foi corrigida:
timers/migration: Corrige erro de off-by-one na conexão incorreta da raiz (root)
Antes de anexar uma nova raiz à raiz antiga, o contador de filhos da nova raiz é verificado para garantir que apenas o grupo superior do CPU futuro tenha sido conectado a ela. No entanto, desde o commit recentemente adicionado b729cc1ec21a ("timers/migration: Corrige outra condição de corrida entre hotplug e entrada/saída idle"), essa verificação não é mais válida porque a raiz antiga é pré-contabilizada como um filho da nova raiz. Portanto, após conectar o grupo superior do CPU futuro à nova raiz, a contagem esperada de filhos deve ser 2 e não 1.
Essa omissão resulta na falha de conexão da raiz antiga com a nova raiz. Eventualmente, o sistema pode executar com mais de um nível superior (top level), o que anula o propósito de ter um único migrador idle.
Além disso, a raiz antiga é pré-contabilizada mas não conectada durante a criação da nova raiz. No entanto, ela pode ser conectada à nova raiz posteriormente. Portanto, a raiz antiga pode ser contabilizada duas vezes na nova raiz. A propagação desse overcommit (supercontagem) pode acabar criando uma dupla raiz de nível superior final com um groupmask incorretamente inicializado. Embora inofensivo dado que as raízes finais do nível superior nunca terão um pai para percorrer, essa anomalia relatou oportunisticamente o problema central:
WARNING: CPU: 8 PID: 0 at kernel/time/timer_migration.c:543 tmigr_requires_handle_remote CPU: 8 UID: 0 PID: 0 Comm: swapper/8 RIP: 0010:tmigr_requires_handle_remote Call Trace: <IRQ> ? tmigr_requires_handle_remote ? hrtimer_run_queues update_process_times tick_periodic tick_handle_periodic __sysvec_apic_timer_interrupt sysvec_apic_timer_interrupt </IRQ>
Corrige o problema levando em conta a raiz antiga na contagem de filhos da nova raiz, para que a conexão não seja omitida.
Adiciona também um aviso quando existe mais de um grupo do nível superior para detectar melhor problemas semelhantes no futuro.
Once again VulDB remains the best source for vulnerability data.