DirtyAH6 y otros tres fallos del kernel: instala RHSB-2026-011
El 19 de septiembre de 2026 Red Hat publicó cuatro fallos locales de elevación de privilegios en la pila de red del kernel. No son el Fragnesia de octubre. Igual hay que reiniciar.
El boletín RHSB-2026-011 de Red Hat, público el 19 de septiembre de 2026 y actualizado el 26, nombra cuatro fallos: CVE-2026-80844 (DirtyAH6), CVE-2026-81000 (TUNderflow), CVE-2026-68121 (PPPoEject) y CVE-2026-74469 (DiagSpill). Cada uno está en una parte distinta de la pila de red. Los cuatro pueden llevar a root cuando se cumplen sus condiciones.
Es una cola distinta de CVE-2026-46300 (Fragnesia), que CISA listó a finales de octubre. Un equipo parcheado para uno no está parcheado para el otro.
Qué dijo Red Hat que cambió
DirtyAH6, TUNderflow y PPPoEject los alcanza un usuario local que puede crear un user namespace y un network namespace, o un proceso que ya tiene las capacidades de red dentro de un namespace que controla. DiagSpill no necesita un user namespace nuevo. Red Hat dice además que DiagSpill puede ser una denegación de servicio remota en configuraciones concretas de SCTP cuando un proceso local pide diagnósticos.
El boletín califica el conjunto como Important. No describe un ataque de paso contra un servidor web. Describe a un usuario con sesión, o a un contenedor, volviéndose root. En un builder compartido eso es el incidente entero.
Dónde un fallo local del kernel es el incidente
Los runners de integración, los notebooks compartidos y los nodos de Kubernetes que permiten user namespaces sin privilegios son el camino ordinario que nombra Red Hat. Un escape de contenedor que termina en uno de estos fallos ya no está contenido. El vecino del nodo es el siguiente paso, no otro ticket.
La nota de denegación de servicio de DiagSpill importa en equipos que hablan SCTP y lo exponen. Si no corres SCTP, esa cláusula no es tu caída. Las cláusulas de escalada local sí lo son.
Qué significa 'corregido' en este boletín
Red Hat dijo el 26 de septiembre de 2026 que había correcciones para muchas líneas de producto y que aceleraba el resto. La acción es la errata del producto que pagas, no un kernel compilado de una lista de correo porque el apodo sonaba urgente.
Otras distribuciones publicaron actualizaciones equivalentes en su calendario. Cruza los números — CVE-2026-80844, CVE-2026-81000, CVE-2026-68121, CVE-2026-74469 — con el aviso de tu proveedor. Una línea genérica de 'kernel actualizado en septiembre' en un ticket no prueba que estos cuatro vayan dentro.
Actualiza, reinicia y estrecha los namespaces
Instala el kernel del proveedor que liste estos CVE y reinicia. Comprueba la versión en ejecución después. En equipos que no necesitan user namespaces sin privilegios, apaga esa función si tu plataforma la documenta como la mitigación que corta el camino ordinario de DirtyAH6, TUNderflow y PPPoEject. Red Hat es explícito: un proceso que ya tiene las capacidades todavía puede alcanzar esos tres.
No trates una actualización del runtime de contenedores como sustituto. El fallo está en el kernel que esos contenedores comparten. Este artículo no incluye una forma de disparar los fallos.
Boletín de Red Hat RHSB-2026-011, público el 19 de septiembre de 2026 y actualizado el 26 de septiembre de 2026.
https://access.redhat.com/security/vulnerabilities/RHSB-2026-011
Preguntas frecuentes
¿DirtyAH6 es el mismo fallo que Fragnesia?
No. DirtyAH6 es CVE-2026-80844, en el boletín de septiembre RHSB-2026-011 de Red Hat. Fragnesia es CVE-2026-46300, listado por CISA el 28 de octubre de 2026. Hay que parchear los dos.
¿Un visitante remoto puede alcanzar DirtyAH6 directamente?
Red Hat describe un usuario local o un proceso con capacidades de red en un namespace. DiagSpill añade un caso de denegación de servicio en configuraciones concretas de SCTP. No es ejecución remota sin autenticación en el servidor web.
¿Instalar el paquete cierra el cambio?
Tiene que arrancar el kernel nuevo. Confirma el build en ejecución después del reinicio, y confirma que el aviso nombra los cuatro CVE.