CVE-2026-80916 in Linux
Sumário
de VulDB • 09/09/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
kcov: corrige corrupção de dados e condições de corrida em PREEMPT_RT
O syzbot está relatando corrupção no estado do KCOV em kernels com PREEMPT_RT, pois o armazenamento temporário usado para salvar/restaurar o estado remoto do KCOV é atualmente alocado como uma área por CPU (per-CPU).
Em kernels com PREEMPT_RT, os manipuladores de softirq são executados como threads de tarefas preemptíveis (por exemplo, ksoftirqd). Se um contexto de softirq preempcionar uma tarefa que está executando uma sessão remota do KCOV, ele salva com segurança o estado da tarefa na área por CPU. No entanto, se essa thread de softirq for subsequentemente preempcionada por outra thread de softirq de maior prioridade no mesmo processador, o segundo softirq sobrescreverá a mesma área por CPU, destruindo permanentemente o estado do KCOV da tarefa original.
Corrija esta corrupção de dados movendo o armazenamento temporário da área por CPU para a área por thread (per-thread). Como cada thread de softirq agora possui seu próprio contexto de tarefa, a preempção aninhada de softirq não causa mais sobrescritas de dados.
Observe que, embora o armazenamento temporário esteja agora em uma base por thread, o kcov_percpu_data.lock da área por CPU deve ser mantido, pois precisamos garantir que kcov_remote_start() e kcov_remote_stop() operem atomicamente sem sofrer condições de corrida contra interrupções assíncronas que manipulam o estado do KCOV da tarefa atual.
É provável que a alocação GFP_KERNEL feita por vmalloc_node() em kcov_init() já tenha chamado panic() antes de retornar NULL, pois não haverá processos userspace passíveis de OOM-kill quando a função __init de um módulo embutido for executada. No entanto, este patch também corrige o travamento do kernel quando vmalloc_node() em kcov_init() retorna NULL, pois kcov_init() deixa per-CPU irq_area == NULL, mas kcov_remote_start() depende de per-CPU irq_area != NULL, resultando nos seguintes problemas:
(1) execução de vmalloc() em kcov_remote_start() apesar do contexto !in_task()
(2) acesso fora dos limites da matriz se (1) for bem-sucedido, mas kcov->remote_size < CONFIG_KCOV_IRQ_AREA_SIZE
(3) vazamento constante de memória alocada por (1), eventualmente eliminando todos os processos userspace passíveis de OOM-kill
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.