Una nueva vulnerabilidad crítica en CentOS 9 ha encendido las alarmas en la comunidad Linux. Se trata de un use-after-free (UAF) en el kernel de Linux, específicamente en el queuing discipline (Qdisc) CAKE, que permite a un atacante local escalar privilegios hasta root. El fallo fue divulgado públicamente el 5 de febrero de 2026 por SSD Secure Disclosure y cuenta con prueba de concepto (PoC) funcional.
Aunque todavía no existe un CVE ni puntuación CVSS oficial, el impacto es alto, ya que permite ejecución de código arbitrario en contexto kernel en sistemas CentOS 9 que utilicen CAKE en configuraciones de tráfico avanzadas.
¿Qué es CAKE y por qué es relevante?
CAKE (Common Applications Kept Enhanced) es un Qdisc moderno utilizado en Linux para traffic shaping y bufferbloat mitigation. Es común en:
-
Gateways
-
Routers Linux
-
Entornos con QoS avanzado
-
Configuraciones con tc, especialmente cuando se combina con Qdisc classful como HFSC
CentOS 9 incluye kernels suficientemente recientes como para verse afectados cuando CAKE se usa en configuraciones apiladas.
Análisis técnico de la vulnerabilidad
El problema se encuentra en la función cake_enqueue() del kernel Linux.
Comportamiento incorrecto clave
Cuando el buffer supera el límite configurado:
if (q->buffer_used > q->buffer_limit) {
// se descartan paquetes
}
return NET_XMIT_SUCCESS; // Estado incorrecto
CAKE descarta paquetes, pero aun así devuelve NET_XMIT_SUCCESS, lo que engaña al Qdisc padre (por ejemplo HFSC), haciéndole creer que el paquete fue encolado correctamente.
Cadena de explotación (HFSC + CAKE)
En una configuración HFSC sobre CAKE, ocurre lo siguiente:
-
HFSC encola paquetes en CAKE, sin verificar errores.
-
HFSC llama a init_ed() y agrega la clase a su lista activa.
-
El administrador elimina la clase HFSC.
-
Esto purga el Qdisc hijo (CAKE) mediante qdisc_purge_queue.
-
Como CAKE ya está vacío, qlen_notify() no elimina la clase de la lista activa de HFSC.
-
Queda un puntero colgante (dangling pointer).
-
En hfsc_dequeue(), el árbol de HFSC selecciona la clase ya liberada.
-
Se produce un use-after-free en cl->qdisc.
Resultado: control del flujo de ejecución del kernel.
Detalles del exploit (PoC)
Según el advisory técnico, el exploit:
-
Bypassea KASLR usando ataques de temporización por prefetch side-channel
-
Rocía Qdiscs falsos mediante sendmsg() y mensajes de control especialmente diseñados
-
Controla el RIP usando gadgets ROP en un Qdisc falso
-
Sobrescribe modprobe_path
-
Dispara modprobe con un tipo de archivo no reconocido
-
Obtiene shell root
Todo esto sin necesidad de credenciales elevadas, únicamente acceso local.
Impacto en CentOS 9
-
Tipo: Local Privilege Escalation (LPE)
-
Acceso requerido: Usuario local
-
Resultado: Root
-
Componentes afectados: Linux kernel (traffic control – CAKE + HFSC)
-
Estado del parche: ❌ No disponible al momento
Red Hat fue notificado hace más de 90 días. La respuesta oficial hasta ahora es: “Work in progress, no release yet”.
Mitigaciones recomendadas (acciones inmediatas)
Mientras no exista un parche oficial, se recomienda:
1. Evitar el uso de CAKE
Eliminar CAKE del sistema, especialmente en lo o interfaces no críticas:
tc qdisc del dev lo root
O migrar a alternativas como HTB si el caso de uso lo permite.
2. Auditar configuraciones de traffic control
tc qdisc show tc class show
Buscar configuraciones HFSC + CAKE o Qdiscs apilados innecesarios.
3. Monitorear actividad sospechosa
-
Uso anómalo de tc
-
Tráfico netlink inusual
-
Creación y eliminación frecuente de clases/Qdiscs
4. Reducir superficie de ataque
-
Deshabilitar módulos de Qdisc no utilizados
-
Ejecutar cargas riesgosas en namespaces, containers o con user isolation
-
Aplicar hardening del kernel cuando sea posible
Conclusión
Esta vulnerabilidad vuelve a demostrar que el subsystem de traffic control del kernel Linux sigue siendo una superficie de ataque compleja y sensible, especialmente en entornos donde se combinan Qdiscs avanzados.
👉 Recomendación clara:
Si administras sistemas CentOS 9 y no necesitas CAKE, elimínalo de inmediato. Si lo usas en producción, audita tus configuraciones, limita el acceso local y mantente atento a las actualizaciones del kernel en cuanto Red Hat publique el parche.
La mitigación temprana es clave: una LPE en kernel siempre debe tratarse como crítica, incluso si requiere acceso local.
