Algunas de las fallas alcanzan una gravedad de 9 sobre 10 y sus detalles técnicos quedaron disponibles antes de que las correcciones llegaran a las versiones oficiales. El incidente reabre el debate sobre los riesgos de divulgar vulnerabilidades sin coordinar previamente su resolución.
Una divulgación aparentemente accidental puso en una situación delicada a los desarrolladores del kernel de Linux. El programa Zero Day Initiative (ZDI), perteneciente a Trend Micro, publicó información técnica sobre varias vulnerabilidades de seguridad en listas de correo públicas utilizadas por los desarrolladores del sistema operativo.
El problema no fue únicamente que se revelaran vulnerabilidades graves. La información quedó disponible públicamente cuando las correcciones todavía no habían sido incorporadas al kernel principal, ofreciendo a potenciales atacantes detalles que podrían facilitar el desarrollo de exploits.
El incidente fue reportado el 22 de octubre por el medio especializado Phoronix, que identificó seis vulnerabilidades divulgadas entre el 20 y el 21 de octubre de 2026.
Dos de ellas afectan a KSMBD, la implementación del servidor SMB integrada en el kernel de Linux, y recibieron una puntuación CVSS de 9.0, correspondiente a una gravedad crítica.
La situación provocó una reacción inmediata de Greg Kroah-Hartman, uno de los principales responsables del mantenimiento del kernel, quien cuestionó públicamente el procedimiento utilizado por Trend Micro.
Dos vulnerabilidades críticas permiten la ejecución remota de código
Los problemas más graves afectan a KSMBD, un componente que permite a sistemas Linux ofrecer servicios de compartición de archivos mediante el protocolo SMB, ampliamente utilizado en redes corporativas y entornos donde conviven equipos Linux y Windows.
A diferencia de Samba, que implementa SMB principalmente en el espacio de usuario, KSMBD ejecuta buena parte de su funcionalidad directamente dentro del kernel.
Esta diferencia tiene implicaciones importantes para la seguridad: una vulnerabilidad que permita ejecutar código dentro del kernel puede comprometer el nivel más privilegiado del sistema operativo.
Las dos fallas identificadas son:
ZDI-CAN-33549: desbordamiento inferior de enteros en SMB Direct
La primera vulnerabilidad afecta al procesamiento de conexiones SMB Direct, una tecnología que utiliza RDMA (Remote Direct Memory Access) para transferir información entre equipos con menor intervención de la CPU.
El problema está relacionado con un integer underflow, una operación aritmética que produce un valor inferior al mínimo representable por el tipo de dato utilizado.
En determinadas circunstancias, este comportamiento puede provocar errores en el manejo de memoria y abrir la posibilidad de ejecutar código arbitrario.
La vulnerabilidad recibió una puntuación CVSS de 9.0.
Según Phoronix, ya existía una corrección en una rama de desarrollo destinada a Linux 7.5, aunque todavía no había sido integrada en la versión principal del kernel cuando se produjo la divulgación.
ZDI-CAN-33774: condición de carrera en KSMBD
La segunda vulnerabilidad también recibió una puntuación CVSS de 9.0 y afecta al procesamiento de solicitudes SMB.
En este caso, el origen del problema es una condición de carrera (race condition): una situación en la que el comportamiento de un programa depende del orden o del momento en que se ejecutan determinadas operaciones concurrentes.
Un atacante podría aprovechar esta condición para provocar un comportamiento inesperado en el servidor y potencialmente ejecutar código de manera remota.
Los reportes técnicos indican que la vulnerabilidad podría explotarse sin autenticación previa, lo que aumenta considerablemente su gravedad cuando el servicio vulnerable resulta accesible desde la red.
Esto no significa que todos los sistemas Linux sean vulnerables. El riesgo depende de que los componentes afectados estén presentes, habilitados y expuestos en las condiciones necesarias para cada ataque.
Otras cuatro vulnerabilidades también quedaron expuestas
Además de los dos problemas críticos de KSMBD, los reportes publicados incluyen otras cuatro vulnerabilidades que afectan a distintos componentes del ecosistema Linux.
ZDI-CAN-33367: escalada local de privilegios en el subsistema de red
Afecta a la función skb_zerocopy(), utilizada en operaciones de red que buscan reducir las copias de memoria durante la transferencia de datos.
Un error en la gestión de los recursos podría permitir que un atacante con acceso local eleve sus privilegios.
Los desarrolladores del kernel indicaron que ya habían recibido un reporte independiente sobre el mismo problema y que se estaba preparando una corrección.
ZDI-CAN-34068: escritura fuera de límites en el controlador gráfico VMware
La vulnerabilidad afecta a VMWGFX, el controlador gráfico utilizado en determinados entornos virtualizados con tecnología VMware.
El problema consiste en una escritura fuera de los límites de memoria asignados, una condición que podría permitir una escalada local de privilegios.
ZDI-CAN-34076: divulgación de información en el subsistema NVMe
Esta falla afecta al código NVMET, utilizado para implementar dispositivos de almacenamiento NVMe accesibles a través de una red.
El uso de un recurso sin inicializar correctamente podría provocar la exposición de información que debería permanecer protegida.
ZDI-CAN-32005: desbordamiento de búfer en el procesamiento de consultas DNS
El sexto reporte describe un desbordamiento de búfer en la pila durante el procesamiento de consultas DNS sobre TCP relacionadas con dominios de búsqueda.
El problema podría facilitar una escalada local de privilegios.
A diferencia de las anteriores, esta vulnerabilidad fue divulgada el 20 de octubre, un día antes de la publicación de los otros reportes.
En conjunto, las seis vulnerabilidades afectan a componentes diferentes y requieren condiciones de explotación distintas. No existe evidencia suficiente para afirmar que todas puedan explotarse remotamente ni que representen el mismo nivel de exposición.
La respuesta de los desarrolladores: «Corrijan su proceso de envío»
La publicación provocó una reacción particularmente crítica de Greg Kroah-Hartman, uno de los desarrolladores más influyentes del proyecto Linux y responsable del mantenimiento de sus versiones estables.
Los mensajes de Trend Micro fueron enviados a listas públicas de desarrollo, pese a que incluían información sobre vulnerabilidades que todavía no contaban con correcciones disponibles para los usuarios.
En una de sus respuestas, Kroah-Hartman cuestionó que se hubiera divulgado el problema sin acompañarlo de un parche.
En otra intervención fue todavía más directo:
«Please fix your submission process...»
Es decir: «Por favor, corrijan su proceso de envío».
La crítica apunta a una cuestión central en la gestión de vulnerabilidades: la diferencia entre comunicar un problema a los responsables de corregirlo y divulgar públicamente la información necesaria para comprenderlo o reproducirlo.
El proyecto Linux dispone de canales privados para recibir reportes de seguridad, precisamente para permitir que los desarrolladores investiguen y preparen correcciones antes de que los detalles técnicos queden expuestos.
En este caso, los mensajes también llegaron a listas públicas, lo que hizo accesible su contenido a cualquier persona.
Aunque todo indica que se trató de un error en el procedimiento de divulgación, no se ha establecido públicamente una explicación definitiva sobre cómo ocurrió.
El problema de divulgar vulnerabilidades antes de corregirlas
La divulgación coordinada de vulnerabilidades es uno de los mecanismos fundamentales de la seguridad informática moderna.
Habitualmente, cuando un investigador descubre una falla, comunica sus hallazgos al fabricante o al equipo responsable del software. A partir de ese momento comienza un proceso que puede incluir la validación técnica, el desarrollo de un parche, las pruebas de funcionamiento y la publicación de un aviso de seguridad.
El objetivo es reducir el tiempo durante el cual una vulnerabilidad resulta conocida públicamente, pero sus potenciales víctimas todavía no disponen de una solución.
Sin embargo, este modelo también genera tensiones.
Los investigadores necesitan mecanismos que eviten que los fabricantes ignoren los problemas reportados. Por eso existen políticas de divulgación que establecen plazos máximos antes de publicar los detalles, incluso cuando todavía no se ha desarrollado una corrección.
El problema de este incidente es diferente.
No se trató de una divulgación pública deliberada después de agotar un plazo de corrección, sino de la publicación aparentemente accidental de información técnica en canales abiertos.
Algunos de los reportes incluían detalles sobre las condiciones necesarias para reproducir las fallas y, según la información publicada, al menos uno contenía código de prueba de concepto (proof of concept).
La disponibilidad de estos materiales puede reducir el esfuerzo necesario para desarrollar herramientas de explotación.
Esto no implica que los atacantes dispongan automáticamente de exploits funcionales, pero sí puede acelerar su investigación.
¿Qué deberían hacer los administradores de sistemas Linux?
La prioridad inmediata es identificar si existen sistemas que utilicen los componentes afectados, especialmente servidores con KSMBD habilitado.
En el caso de las dos vulnerabilidades más graves, conviene prestar especial atención a los servicios SMB accesibles desde redes no confiables.
Las principales medidas de mitigación incluyen:
Identificar servidores con KSMBD habilitado: verificar qué equipos utilizan el servidor SMB integrado en el kernel y si realmente necesitan ese servicio.
Restringir el acceso al puerto TCP 445: limitar las conexiones SMB a los segmentos de red y equipos autorizados.
Revisar el uso de SMB Direct: identificar sistemas que utilicen RDMA y evaluar la necesidad de mantener habilitada esta funcionalidad.
Deshabilitar servicios innecesarios: reducir la superficie de ataque mientras no existan correcciones disponibles.
Monitorear las actualizaciones del kernel: seguir los avisos de seguridad de las distribuciones utilizadas, ya que pueden incorporar correcciones antes o independientemente de una nueva versión principal.
Revisar los registros y eventos de seguridad: prestar atención a comportamientos anómalos en servicios SMB y componentes afectados.
Es importante evitar una interpretación equivocada: instalar cualquier actualización disponible no garantiza que estas vulnerabilidades hayan sido corregidas.
Los administradores deben verificar específicamente si su distribución incorporó los parches correspondientes.
Tampoco es recomendable instalar indiscriminadamente versiones experimentales del kernel en sistemas de producción, dado que podrían introducir problemas adicionales de estabilidad o compatibilidad.
Un incidente que expone una debilidad del proceso de seguridad
El episodio resulta especialmente llamativo porque involucra a Trend Micro, una empresa dedicada a la ciberseguridad, y a su programa Zero Day Initiative, especializado precisamente en descubrir, gestionar y coordinar la divulgación de vulnerabilidades.
La situación demuestra que incluso organizaciones con amplia experiencia en investigación de seguridad pueden introducir riesgos mediante errores operativos.
En este caso, el problema no estuvo en la investigación de las vulnerabilidades, sino en el procedimiento utilizado para comunicar los hallazgos.
La diferencia es importante: descubrir una falla contribuye a mejorar la seguridad, pero divulgar sus detalles antes de que exista una solución puede ampliar temporalmente la exposición de los sistemas afectados.
Al momento de los primeros reportes, algunas correcciones ya estaban en desarrollo y otras habían sido identificadas previamente por investigadores independientes. Sin embargo, no todas estaban disponibles en versiones estables del kernel.
Hasta el 24 de octubre no hay información suficientemente verificada que permita afirmar que estas vulnerabilidades estén siendo explotadas activamente en ataques reales.
La ausencia de evidencia pública de explotación tampoco significa que el riesgo sea inexistente.
El incidente deja una advertencia concreta para la industria: la seguridad de una vulnerabilidad no depende solamente de la calidad de su investigación o de la rapidez con que se desarrolla un parche. También depende de cómo se administra la información durante el período previo a su corrección.
En un ecosistema tan extendido como Linux, donde el mismo kernel puede utilizarse en servidores empresariales, plataformas de virtualización, dispositivos de red e infraestructura crítica, un error en ese proceso puede tener consecuencias que trascienden ampliamente a los investigadores y desarrolladores involucrados.