← Volver a artículos
Seguridad· 3 min de lectura

FRRouting en RHEL 10: dos fallos de denegación de servicio en bgpd (RHSA-2026:24347)

Red Hat publicó el 8 de junio de 2026 el aviso RHSA-2026:24347, que corrige dos vulnerabilidades de denegación de servicio en FRRouting (paquete frr) sobre Red Hat Enterprise Linux 10. Las dos comparten el mismo síntoma: tiran el demonio bgpd, y cuando ese proceso cae se retiran del kernel todas las rutas aprendidas por BGP. El tráfico que dependía de esas rutas se queda sin camino. En un router de tránsito o en la interconexión de dos centros de datos, una caída así no es un susto local, se propaga.

FRRouting es la suite de routing que mucha gente usa en RHEL para hablar BGP, OSPF, IS-IS o RIP. Aquí los dos fallos están en la parte de BGP, y ambos se disparan procesando un mensaje BGP UPDATE recibido de un peer.

CVE-2026-37457: off-by-one en el parser de FlowSpec

El primero está en bgp_flowspec_op_decode(), dentro de bgpd/bgp_flowspec_util.c. El campo de tipo de componente de un sub-TLV de FlowSpec se usa en una comprobación de límites que está desplazada en uno. Con un valor elegido a propósito, el parser escribe un byte más allá del buffer reservado en el heap. Es una escritura fuera de límites de un solo byte, suficiente para corromper memoria y hacer caer bgpd.

Para explotarlo hay que poder enviar mensajes BGP UPDATE al hablante FRR vulnerable, es decir, tener (o falsear) una sesión BGP con él. No es trivial desde fuera si tu BGP está bien filtrado, pero entre operadores y en redes con muchos peers el modelo de confianza es más amplio de lo que parece.

CVE-2026-37459: underflow al procesar un TLV NHC

El segundo es un underflow de entero. Afecta a las ramas estables de FRR de la 10.0 a la 10.6. El demonio procesa un BGP UPDATE con un campo Next Hop Capability (NHC) de tipo-longitud-valor mal formado. Cuando tlv_length se ajusta para quedar justo por debajo de la longitud restante del buffer, la resta length -= tlv_length + BGP_NHC_TLV_MIN_LEN se desborda hacia abajo y produce un valor sin signo enorme. A partir de ahí el parser lee donde no debe y el proceso revienta.

El vector vuelve a ser un BGP UPDATE manipulado. Mismo resultado: bgpd se cae y las rutas desaparecen.

A quién afecta y cómo de grave es

Red Hat clasifica el aviso como Important. No hay ejecución de código en juego según el análisis publicado, solo denegación de servicio, pero en infraestructura de red eso ya es serio. El impacto real depende de tu topología: si bgpd es la pieza que sostiene tu tabla de forwarding, perderla deja al equipo aislado hasta que el demonio reinicia y reconverge.

Afecta a las instalaciones de FRRouting en RHEL 10. Otras distribuciones publicaron sus propios avisos para los mismos CVE (por ejemplo Ubuntu en USN-8376-1), así que conviene revisar tu canal de actualizaciones según la distro.

Mitigación

La corrección está en FRR 10.4.4. En RHEL 10 el paquete actualizado es frr-10.4.4-1.el10_2:

sudo dnf update frr
sudo systemctl restart frr

Ten en cuenta que reiniciar frr provoca una reconvergencia de las sesiones BGP, así que planifícalo o usa graceful restart si lo tienes configurado. Como medida de defensa adicional, restringe con quién levantas sesiones BGP y aplica filtros estrictos de prefijos y de peers: cuanto menos arbitrario sea quién puede mandarte un UPDATE, menor es la superficie para estos dos fallos.

Si gestionas equipos con Red Hat Enterprise Linux, revisa también las versiones de FRR en cualquier appliance o imagen derivada que tengas en producción.

Fuente