Las vulnerabilidades del kernel de Linux no se notifican con antelación a las distribuciones

• CopyFail, una vulnerabilidad de escalada local de privilegios en el kernel de Linux, entra en la categoría de las más graves entre las vulnerabilidades recientes de tipo “make-me-root” (que convierten a un usuario normal en root)
• Esta vulnerabilidad fue introducida en un commit específico de la versión 4.14 del kernel, y coincide con el momento en que se añadió la optimización in-place del módulo authencesn utilizada por CopyFail
• La corrección se incorporó en los kernels 6.18.22, 6.19.12 y 7.0, y las versiones 6.18.22 y 6.19.12 se lanzaron el 11 de abril con la corrección ya backporteada (aplicar a una versión anterior un parche de una versión superior)
• Sin embargo, los kernels Longterm todavía muy utilizados (6.12, 6.6, 6.1, 5.15, 5.10) aún no incluyen esa corrección, y tampoco se ha confirmado en la upstream stable queue
  • Como el problema fue introducido en 2017, es necesario verificar si estos kernels Longterm antiguos también están afectados
• El parche de corrección no hace clean apply (se aplica limpiamente sin conflictos de código) en kernels antiguos, y debido a varios cambios de API es difícil avanzar con confianza incluso al intentar backportearlo
• En entornos que requieren una respuesta inmediata, como medida temporal se puede aplicar un parche para desactivar el módulo authencesn de IPSec; incluso sin ser experto en IPSec, sería una “opción no perfecta, pero menos mala”
• Es decir, el problema estructural está en el propio proceso de divulgación de vulnerabilidades del kernel de Linux:
  • A menos que quien reporta la vulnerabilidad lo notifique directamente a la lista de correo linux-distros (un canal privado donde se reúnen los equipos de seguridad de las distribuciones), las distribuciones no reciben una alerta previa
  • En este caso de CopyFail tampoco hubo una advertencia previa (heads-up) a través de la lista linux-distros
  • En otras palabras, los equipos de seguridad de las principales distribuciones como Ubuntu, RHEL y SUSE no tuvieron la oportunidad de preparar parches antes de la divulgación de la vulnerabilidad

[unsure4000]

Aunque la entrada del blog es un poco infantil, creo que para considerarlo como algo más que alguien antipático, el problema sistémico es una falla mucho mayor.

[GN⁺]

Comentarios en Hacker News

• Sam James, el autor del artículo enlazado, es desarrollador de Gentoo
  En cualquier caso, esto estuvo cerca de ser un desastre, y fue muy irresponsable publicar el exploit antes de que las distribuciones pudieran desplegar los arreglos
  No hay forma de saber cuántos proveedores de hosting compartido habrán sido comprometidos por esto
  También preocupa que no parezca haber comunicación entre el kernel security team y los maintainers de las distribuciones
  Uno esperaría que los primeros avisaran a los segundos, pero en la práctica parece una estructura donde la responsabilidad recae en quien descubre la vulnerabilidad

  • No veo problema en hacerlo público 30 días después de que el parche haya llegado al destinatario del reporte
    Como referencia, Google Project Zero usa una política similar de “90+30”: https://projectzero.google/vulnerability-disclosure-policy.h...
    El verdadero problema es que no existe un canal de comunicación entre el kernel security team y los maintainers de las distribuciones
    La persona que descubre la vulnerabilidad no debería cargar con la responsabilidad de reportarla por separado a todos los downstream
    El equipo del kernel debió avisar a la lista de responsables de seguridad de las distribuciones sobre la severidad del parche y la fecha de divulgación 30 días después
  • Esta divulgación estuvo más cerca del marketing que de la seguridad
    En la página de divulgación aparecen frases como “Is your software AI-era safe?”, “Copy Fail was surfaced by Xint Code about an hour of scan time against the Linux crypto/ subsystem”, y “[Try Xint Code]”
    Es una forma de hacer que el producto se vea más atractivo mientras más confusión genere
  • Como usuario y administrador, no estoy de acuerdo con que esto haya sido “muy irresponsable”
    La expresión Responsible Disclosure, igual que “Secure Boot”, está lingüísticamente muy bien diseñada, pero en la práctica parece servir para gestionar la reputación de las organizaciones intermedias —empresas y fundaciones— que están entre mi computadora y yo
    A ellos les interesa más evitar que se diga “RHEL es vulnerable” o “Ubuntu es vulnerable” que saber si mi computadora individual está expuesta
    La vulnerabilidad existe de todos modos, así que prefiero tener la oportunidad de conocer el riesgo y mitigarlo en vez de solo esperar a que lo arreglen en silencio
    Es decir, creo que la divulgación inmediata es la única opción que no es irresponsable
  • Independientemente de la postura sobre el proceso de divulgación, si un proveedor de hosting fue comprometido por esto, su diseño ya estaba condenado a perder
    No es aceptable ejecutar cargas de trabajo de tenants que no confían entre sí bajo un único kernel compartido
    Los LPE del kernel no son raros, y este en particular solo era especialmente simple y portable, mientras que la capacidad ofensiva básica ya es casi un commodity del CNE
  • El Linux kernel no es adecuado para usarse como frontera de seguridad
    Si haces shared hosting y no quieres que te comprometan, deberías usar otros mecanismos como gVisor o VMs con Firecracker
    Android es más o menos el único sistema importante que sí lo usa como frontera de seguridad, y lo mitiga con aprobación del usuario para instalar APKs, políticas estrictas de SELinux y seccomp, y el hardening de GrapheneOS
    En este caso la mitigación sí funcionó: https://discuss.grapheneos.org/d/35110-grapheneos-is-protect...

• No entiendo por qué se dice algo como “en el caso de una vulnerabilidad del Linux kernel, las distribuciones no reciben aviso previo a menos que el reporter la lleve directamente a la lista linux-distros ML”
  Que el reporter tenga que coordinarse directamente con las distribuciones presupone un nivel alto de conocimiento del proyecto Linux
  Quien reporta una vulnerabilidad no debería ser responsable de trabajar directamente con todos los consumidores downstream del Linux kernel
  Bajo esa lógica, también habría que contactar individualmente a todos los fabricantes que usan Linux en sus equipos
  Considero que el reportero ya hizo suficiente con divulgar responsablemente a Linux y esperar hasta que el parche estuviera integrado
  Dentro del proyecto Linux debería haber personas con autoridad y responsabilidad sobre las vulnerabilidades de seguridad, y ellas deberían encargarse de avisar a las distribuciones downstream

  • Más aún porque se les pide explícitamente a los reporters que no avisen primero a los equipos de las distribuciones
    https://docs.kernel.org/process/security-bugs.html
    As such, the kernel security team strongly recommends that as a reporter of a potential security issue you DO NOT contact the “linux-distros” mailing list UNTIL a fix is accepted by the affected code’s maintainers and you have read the distros wiki page above and you fully understand the requirements that contacting “linux-distros” will impose on you and the kernel community.
  • El reporter sí tuvo tiempo para revisar y mencionar explícitamente distribuciones concretas como Ubuntu/RHEL/SUSE en su sitio web
    Como mínimo, habría sido responsable avisar a los equipos de seguridad de esas distribuciones
  • Cuesta ver como razonable que el reporter haya creado un sitio web que señala explícitamente a Ubuntu, RedHat, Amazon y SUSE, y aun así no les haya avisado
    Tampoco parece creíble que no supiera que esas distribuciones son downstream del equipo del kernel
  • Tal vez no sea un requisito obligatorio, pero creo que todos terminaron sufriendo más porque a los reporters les importaba más la notoriedad que una remediation segura
  • Encontrar cómo reportar este tipo de problemas de seguridad a una distribución Linux es muy fácil
    Sale hasta con una búsqueda en Google: https://share.google/aimode/eihDKXZJy94Z5lC1p
    Cuesta entender que no hayan pensado en eso y hayan dejado a todo el mundo expuesto al exploit; en algunas jurisdicciones incluso parecería razonable considerarlo un delito grave

• El intercambio más interesante sobre la divulgación está en este enlace
  https://www.openwall.com/lists/oss-security/2026/05/01/3
  Es la respuesta de greg k-h: “no podemos avisar con antelación a nadie, porque entonces tendríamos que avisar a todo el mundo sobre todo. Esa es la única política que los organismos legales y gubernamentales nos han permitido adoptar para poder operar”

  • Me gusta Linux, pero me parece una política absurda

• Hay que dejar de culpar al reporter y exigir que se arregle el proceso del kernel
  El Linux kernel ya no es un proyecto de juguete, y hay empleados de tiempo completo contratados por varias empresas
  Ellos debieron encargarse de avisar a las distribuciones, no una persona cualquiera

  • Si en una publicación de anuncio, que en la práctica era de marketing, se nombró explícitamente a ciertas distros como afectadas, entonces me parece apropiado y esperable que se les hubiera dado un heads-up antes de hacerlo público
    Probablemente no habría habido tanta crítica si no hubieran incluido menciones como RHEL 14
    No estamos hablando de un investigador individual o del ámbito académico, sino de una empresa de seguridad con un departamento profesional de comunicaciones señalando a maintainers de distros
  • Es cierto que las distribuciones y los desarrolladores del kernel deben comunicarse y moverse rápido ante parches de alta severidad
    Pero como el reporter no esperó a que eso ocurriera, puede que personas reales hayan salido perjudicadas, y esa responsabilidad recae en el reporter
  • Reportar una vulnerabilidad y publicar un exploit potente que cualquiera puede usar son cosas completamente distintas
    Soltarlo al mundo sin avisar antes a las principales distribuciones fue irresponsable

• Para quienes usan un kernel donde AF_ALG está enlazado directamente y no como módulo, alguien publicó un workaround basado en eBPF: https://github.com/Dabbleam/CVE-2026-31431-mitigation
  Lo estoy ejecutando ahora mismo en producción, mitiga el ataque y hasta ahora no se observan efectos secundarios inesperados

• Creo que nosuid y probablemente nodev deberían ser opciones de montaje por defecto del filesystem
  /dev ya es un devtmpfs especial, y si hace falta un /dev mínimo en el initrd, entonces el rootfs tmpfs del initrd podría montarse explícitamente con dev y suid
  Permitir que binarios SUID “existan” en cualquier lugar es un riesgo de seguridad enorme
  Si montas un medio de almacenamiento externo, ¿cómo verificas que los binarios SUID dentro de ese block device no sean maliciosos?
  Además, este exploit parece requerir que el usuario que ejecuta el binario SUID también pueda leer ese binario
  No hay razón para que un usuario no root tenga permiso de lectura sobre un binario SUID
  NixOS maneja esto correctamente
  En /nix/store, que es el directorio normal de instalación de paquetes, no hay SUID, y como los paquetes no se filtran fuera de ahí, se puede usar nosuid con seguridad en otros mountpoints
  La única excepción es un directorio de propósito único, /run/wrappers.$hash, que contiene de forma segura únicamente wrappers SUID solo ejecutables

  • Yo también odio suid, pero aquí suid no es el problema esencial
    El bug explotado permite en la práctica un page cache poisoning arbitrario
    A partir de ese punto, la partida ya está perdida, y aunque parchear programas suid puede ser la forma más fácil de obtener una root shell, no es ni de cerca la única
  • El exploit de prueba de concepto solo muestra literalmente un vector de ataque
    Hay muchas otras formas
    Si el objetivo fuera solo bloquear el exploit de demostración, habría métodos más simples como un blacklist, pero eso no lo vuelve más seguro
    Esta vulnerabilidad permite manipular el page cache
    Podrías manipular ld.so para enganchar cualquier system call, cambiar el uid a 0 o elevar privilegios de muchas otras maneras
    El mount point no tiene nada que ver con este problema
    Claro, bloquear suid en áreas escribibles por usuarios y evitar la lectura de archivos suid siempre es buena idea, pero por otras razones
    NixOS tampoco corrige esta vulnerabilidad y es tan vulnerable como las demás distribuciones
  • Si no hay permiso de lectura, no puedes ejecutar el binario, y eso tiene sentido
    Para ejecutar un binario, hay que leerlo desde disco y cargarlo en memoria
    De hecho, si un binario en particular tiene permiso de lectura pero no de ejecución, también puedes ejecutarlo invocando directamente el linker
    Por ejemplo, llamando a /bin/ld.so.1 /path/to/binary, el linker lee y carga el binario y luego salta a su entry point sin hacer una llamada a exec()

• En el enlace de Bleeping Computer de abajo hay posibles medidas de respuesta mientras se prepara el parche
  https://www.bleepingcomputer.com/news/security/new-linux-cop...

  • Este workaround solo aplica a kernels donde el código afectado fue compilado como módulo
    RHEL, Fedora y Gentoo están configurados para compilar ese código directamente dentro del kernel
    Sin un parche o un cambio de configuración, como insinuó Sam en Gentoo, esas distribuciones seguirán siendo vulnerables
  • En RedHat y sus distribuciones derivadas, el código afectado está compilado estáticamente y no como módulo, así que esta mitigación no funciona

• NixOS tampoco recibió aviso
  https://discourse.nixos.org/t/is-nixos-affected-by-copy-fail...

  • Ninguna distribución recibió aviso

• Hyperbola GNU estuvo a salvo porque todavía usa Python 3.8 por razones políticas y de estabilidad

• Ubuntu ya publicó un parche, y las pruebas antes y después del parche ya se completaron