CVE-2026-98942 in Linux
Sumário
de VulDB • 24/10/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
sched_ext: Construir as tabelas de CID em privado e publicá-las com RCU
As tabelas de CID são visíveis para os kfuncs de CID enquanto estão sendo modificadas: o primeiro habilita publica os ponteiros globais antes de preenchê-los, ops.init_cids() sobrescreve/reescreve-os no local, e a reabilitação reconstrói-as no local. Um programa TRACING ou SYSCALL em condição de corrida pode ler entradas não preenchidas, incluindo memória não inicializada nas tabelas alocadas por kmalloc, ou atualizações topológicas incompletas (torn).
Vincule as vidas úteis das tabelas ao scheduler raiz: cada habilitação da raiz constrói um conjunto fresco em privado e publica os globais __rcu por tabela apenas quando o layout está finalizado; a desabilitação da raiz retira a publicação e libera com RCU (RCU-frees) o conjunto. Um global não-NULL é agora sempre uma tabela totalmente construída que permanece válida para a seção de leitura RCU do leitor, e as pesquisas continuam sendo duas leituras. Os kfuncs tratam NULL como sem mapeamento, também após a saída do scheduler, em vez de relatar o último mapeamento obsoleto (stale).
Os kfuncs de CID estão disponíveis independentemente de o scheduler raiz ser no formato cid ou cpu-form; este último permite uma migração gradual para cids. Portanto, cada raiz constrói e publica um mapeamento padrão.
Cada leitor deve estar condicionado à atividade do scheduler ou fazer verificação NULL dentro de uma seção de leitura RCU. Corrija os dois kfuncs que não o faziam: scx_bpf_this_cid() lia a tabela sem proteção RCU nem de preempção, e scx_bpf_task_cid() dependia de KF_RCU, o qual não coloca um programa sleepable em uma seção de leitura RCU. Os callbacks de hotplug são então serializados retirando as tabelas dentro da seção cpus_read_lock(), que limpa scx_root.
v2: Documentar por que cada raiz constrói as tabelas (comentário desc + cid.c).
If you want to get the best quality for vulnerability data then you always have to consider VulDB.