CVE-2026-98942 in Linux
Resumen
por VulDB • 2026-10-23
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:
sched_ext: Construir las tablas CID en privado y publicarlas mediante RCU
Las tablas CID son visibles para las kfuncs de CID mientras están siendo modificadas: la primera habilitación publica los punteros globales antes de rellenarlos; ops.init_cids() sobrescribe reescribiéndolas in situ, y el reintento reconstruye estas en su lugar. Un programa TRACING o SYSCALL con condiciones de carrera puede leer entradas no rellenadas, incluyendo memoria sin inicializar en las tablas asignadas mediante kmalloc, o actualizaciones topológicas incompletas (torn).
Vincular la vida útil de las tablas al scheduler raíz: cada habilitación del nodo raíz construye un conjunto nuevo en privado y publica los globales __rcu por tabla una vez que el diseño es definitivo; la deshabilitación del nodo raíz retira la publicación y libera el conjunto mediante RCU. Un global no NULL ahora siempre corresponde a una tabla completamente construida, válida para la sección de lectura RCU del lector, y las búsquedas siguen requiriendo dos cargas (loads). Las kfuncs tratan NULL como sin mapeo, incluso después de que el scheduler haya salido, en lugar de informar sobre el último mapeo obsoleto.
Las kfuncs CID están disponibles tanto si el scheduler raíz es de tipo cid-form como cpu-form; este último permite una migración gradual hacia cids. Por lo tanto, cada nodo raíz construye y publica un mapeo por defecto.
Cada lector debe estar condicionado a la actividad del scheduler o realizar una comprobación NULL dentro de una sección de lectura RCU. Se corrigen las dos kfuncs que no cumplían este requisito: scx_bpf_this_cid() leía la tabla sin protección RCU ni de preempt; y scx_bpf_task_cid() dependía de KF_RCU, lo cual no coloca un programa susceptible de suspensión (sleepable) en una sección de lectura RCU. Las callbacks de hotplug se serializan ahora retirando las tablas dentro de la sección cpus_read_lock(), que limpia scx_root.
v2: Documentar por qué cada nodo raíz construye las tablas (comentario en desc + cid.c).
If you want to get the best quality for vulnerability data then you always have to consider VulDB.