La acción gate del subsistema de control de tráfico (net/sched) del kernel Linux arrastraba una condición de carrera que ha quedado registrada como CVE-2026-23245. El problema está en net/sched/act_gate.c y permitía que un usuario local con permisos para configurar el control de tráfico provocara accesos a memoria inconsistentes dentro del kernel.
Qué hace la acción gate y dónde falla
La acción gate forma parte de Time-Aware Shaping, el mecanismo que abre y cierra “puertas” de transmisión según una agenda temporal (ligado a TSN, redes con tiempo garantizado). Esa agenda es una lista de entradas que el kernel recorre periódicamente desde un hrtimer, y que también se lee cuando alguien hace un dump de la configuración del control de tráfico.
El fallo aparece cuando la acción se reemplaza en caliente. Si un usuario sustituye la acción gate mientras el callback del timer o la ruta de dump están recorriendo la lista del schedule, el código liberaba o cambiaba esos parámetros sin sincronización suficiente. Un hilo leía estructuras que otro estaba modificando o liberando. El resultado es acceso a memoria inconsistente, con posibilidad de corrupción y caída del sistema.
A quién afecta
Afecta a sistemas Linux con la pila de control de tráfico habilitada y la acción gate disponible, algo común en kernels de propósito general. Según los datos de NVD el rango de versiones vulnerables es amplio:
- 5.8 hasta 5.10.252
- 6.2 hasta 6.6.129
- 6.7 hasta 6.12.77
- 6.13 hasta 6.18.17
- 6.19 hasta 6.19.7
El vector es local: AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H. Hace falta una cuenta en la máquina y permiso para manipular el control de tráfico (capacidad CAP_NET_ADMIN, normalmente dentro de un namespace de red). No es un fallo explotable a ciegas desde Internet, pero en entornos multiusuario o con contenedores que reciben CAP_NET_ADMIN el riesgo es real.
Gravedad
El CVSS 3.1 asignado por kernel.org es 7.8 (alta), con impacto alto en confidencialidad, integridad y disponibilidad. La condición de carrera puede derivar en lectura de memoria que no corresponde o en una caída del kernel. Las carreras de este tipo son delicadas: dependen de la sincronización exacta entre el timer y la sustitución de la acción, lo que complica un exploit fiable, pero no lo descarta.
Mitigación y parche
La corrección cambia cómo se manejan los parámetros del schedule. En lugar de tocar la lista en vivo, introduce snapshots protegidos por RCU: los parámetros nuevos se intercambian bajo el bloqueo tcf_lock y los antiguos se liberan de forma diferida mediante call_rcu(). Así, cualquier lector que estuviera recorriendo la versión anterior la sigue viendo intacta hasta que termina, y la liberación solo ocurre cuando ya no queda nadie usándola.
Lo que toca hacer es actualizar el kernel a una versión con el parche. Hay siete commits de backport publicados en git.kernel.org que cubren las ramas estables afectadas, así que la mayoría de distribuciones lo recogen en sus actualizaciones de kernel de marzo de 2026 en adelante. Comprueba el aviso de tu distribución (Debian, Ubuntu, SUSE) y aplica la versión corregida. Si por algún motivo no puedes parchear de inmediato, limitar quién tiene CAP_NET_ADMIN y revisar los contenedores con esa capacidad reduce la superficie expuesta.