Tu escáner dice cero críticas y el exploit da root

El 21 de octubre, la Zero Day Initiative de Trend Micro mandó cinco informes de fallos del kernel de Linux al equipo de seguridad del proyecto y, por error, a las listas públicas de desarrollo. Tres de ellos llevaban código de prueba completo. Ninguno tiene CVE, y uno ya ha servido para conseguir root en AlmaLinux, Debian y Ubuntu con kernels que están en producción ahora mismo. Si esta semana le preguntas a tu escáner de vulnerabilidades, te dirá que no hay nada crítico. Y tendrá razón, porque no hay ningún número que contar.

Lo que salió, y por dónde

La secuencia es corta. El 20 de octubre a las 00:17 UTC salió un informe sobre ConnMan, el gestor de conexiones que corre en espacio de usuario. El 21 de octubre salieron otros cinco, estos sí del kernel, dirigidos al equipo de seguridad del proyecto y —por error— con las listas públicas en copia, entre ellas la lista general del kernel y la de red. El 22 de octubre lo recogió Phoronix y Greg Kroah-Hartman, el segundo de a bordo del kernel, fue contestando a los informes para señalar lo que acababa de pasar: eran públicos y habían llegado sin parche.

El que te toca no es el de 9,0

Si ordenas esa tabla por la puntuación, empiezas por los dos nueves y te equivocas de sitio. Los dos nueves son de ksmbd, una pieza que hay que haber encendido a mano y que la mayoría no tiene. El que de verdad mueve el día es el 7,8.

skb_zerocopy() no arrastra una marca que indica que un fragmento de datos está compartido. Sin esa marca, el descifrado de ESP acaba escribiendo sobre datos que viven en la caché de páginas, de modo que un proceso sin privilegios modifica un fichero que puede leer pero que no tiene permiso para abrir en escritura. Es la misma familia que Dirty Pipe, y de ahí a root hay un paso corto. En las pruebas de TuxCare ese paso se dio en AlmaLinux 8, 9 y 10, CloudLinux 9 y 10, Debian 12 y 13, y Ubuntu 24.04 y 26.04. No son ramas de laboratorio: son los kernels que arrancan tus servidores. Y esquiva el arreglo de Dirty Frag (CVE-2026-43284) de mayo: AlmaLinux lo lleva aplicado en las tres versiones, y cae igual.

Ahora el matiz que no sale en los titulares y que decide si esto te quita el sueño: es local. Hace falta que alguien ya pueda ejecutar código sin privilegios en esa máquina. Así que la pregunta no es la puntuación, es quién tiene una consola en ese servidor. Un corredor de integración continua que ejecuta ramas de cualquiera, un alojamiento compartido —que CloudLinux esté en la lista de distribuciones probadas no es casualidad—, contenedores con carga de terceros o un servidor con cuentas de desarrollo: ahí esto es urgente hoy. Una máquina donde entran dos administradores con llave y nadie más es otra conversación. CVSS no sabe cuál de las dos es la tuya. Tú sí.

El número no es un aviso: es un recibo

La política de asignación del propio proyecto lo dice sin rodeos: «No se asignará automáticamente ningún CVE a problemas de seguridad sin corregir del kernel de Linux; la asignación ocurrirá automáticamente sólo después de que exista un arreglo y se haya aplicado a un árbol estable». Y añade otra regla con la que mucha gente tropieza: «No se asignará ningún CVE a un problema encontrado en una versión del kernel que el equipo de Stable/LTS no mantenga activamente».

Nos parece una política correcta y la defendemos: inflar el recuento con identificadores de fallos que nadie puede arreglar todavía no protege a nadie, y alimenta la ficción de que un número es una solución. Pero tiene una consecuencia que se nota el martes por la mañana. Mientras dura la ventana —de «esto es público» a «esto está en una rama estable»— no hay número, y tu cadena de herramientas no tiene dónde ponerlo. El escáner compara versiones instaladas contra una base de datos de CVE. El informe mensual cuenta CVE. El acuerdo de nivel de servicio de parcheo se mide en días desde la publicación del CVE. El panel que ve el comité dice cero críticas, y dice la verdad: no hay ninguna crítica con identificador.

Pon las fechas al lado y la ventana deja de ser un detalle. La política de divulgación de ZDI son 120 días, de modo que la fecha límite para publicar los avisos oficiales de los cinco informes del kernel cae el 18 de febrero de 2027. El CVE llegará cuando el arreglo entre en una rama estable, antes o después de esa fecha, pero siempre después del arreglo. Lo que aparecerá en tu escáner no es una alerta de algo que tienes que hacer: es la confirmación de algo que ya pasó. El número no es un aviso. Es un recibo.

ksmbd no es Samba, y probablemente ni lo tienes

ksmbd es el servidor SMB3 que corre dentro del kernel. No es Samba, que vive en espacio de usuario y es lo que hay en la enorme mayoría de sitios donde alguien comparte una carpeta. Nació buscando rendimiento, y su reparto está explicado en la documentación del kernel: las operaciones ligadas al rendimiento —abrir, leer, escribir, cerrar— van dentro; la gestión DCE/RPC y de cuentas se queda fuera porque es la parte que, cita literal, «históricamente ha dado lugar a numerosos desbordamientos de búfer y errores de seguridad peligrosos». La frase lleva años ahí.

En la configuración del kernel la opción se llama, literalmente, «SMB3 server support (EXPERIMENTAL)». Debian y Ubuntu distribuyen el módulo, pero inerte: no hace nada hasta que alguien instala ksmbd-tools, configura un recurso y arranca el servicio. AlmaLinux y CloudLinux directamente no lo construyen, y Red Hat tampoco lo construye ni lo distribuye. Para tener esto encendido hay que haberlo encendido a propósito. Lo más probable, entonces, es que estos dos nueves no vayan contigo.

Hay un detalle del primero que merece mirarse, porque contradice lo que uno esperaría. La documentación dice que ksmbd implementa los dialectos 2.1, 3.0 y 3.1.1, «excluyendo intencionadamente el dialecto SMB1, vulnerable en seguridad». Y sin embargo el disparador descrito es una ráfaga de paquetes SMB1 cortos seguida de un SMB2 en la misma escritura TCP, que hace que un hilo acabe tratando datos de SMB1 con un manejador de SMB2 y leyendo más allá del final del búfer corto. Las dos cosas son ciertas: ksmbd no descarta SMB1, lo implementa en parte a propósito —mantiene una tabla de operaciones SMB1 con su manejador de negociación— porque la negociación multiprotocolo de SMB1 es la vía legítima por la que un cliente antiguo sube a SMB2. El fallo no está en el dialecto que soportas ni en el que rechazas, sino en el instante en que se cambia de uno a otro. Excluir un dialecto de la lista de funciones no lo saca del código.

Qué comprobar, y las trampas que tiene comprobarlo

En cada máquina Linux que comparta ficheros:

lsmod | grep ksmbd
modinfo ksmbd 2>/dev/null | head -2
systemctl is-enabled ksmbd 2>/dev/null
ss -Hltnp 'sport = :445'
grep -E 'CONFIG_SMB_SERVER(_SMBDIRECT)?=' /boot/config-$(uname -r) \
  || zcat /proc/config.gz | grep -E 'CONFIG_SMB_SERVER(_SMBDIRECT)?='

Las trampas, por orden de probabilidad de que te muerdan. Que lsmod no devuelva nada no cierra el asunto: si el kernel se compiló con CONFIG_SMB_SERVER=y el servidor va dentro y no aparece como módulo. modinfo contesta mejor que la configuración: =m dice con qué se compiló el kernel, no qué fichero está instalado —en Ubuntu el módulo vive en un paquete aparte de módulos extra, y sin ese paquete un modprobe falla—. Y en ss, usa el filtro de puerto en lugar de un grep ':445', que también casa con el 4450 y con el 4455; además, para ksmbd la columna de proceso saldrá vacía, porque quien escucha es el kernel y no hay proceso al que apuntar. Si esperas ver un nombre ahí y no lo ves, no significa que no haya nadie escuchando.

Para el segundo fallo hace falta además una tarjeta con RDMA y CONFIG_SMB_SERVER_SMBDIRECT. Un ls /sys/class/infiniband vacío apunta a que no, con la reserva de que ese directorio puede no existir si el núcleo RDMA no está cargado, y de que RoCE por software se puede crear después sin hardware ninguno.

Si sale que sí y no lo necesitas, lo que sostiene no es descargar el módulo: modprobe -r ksmbd falla si está en uso y nada impide que vuelva a cargarse en el siguiente arranque. Lo que sostiene es enmascarar el servicio y mover el recurso a Samba. No porque el espacio de usuario sea mágico —Samba tiene su propio historial de fallos—, sino porque un desbordamiento dentro del kernel corre con el privilegio del kernel y uno en un demonio corre con el del demonio. Si no puedes apagarlo hoy, la mitigación es de red: el 445 no debería ser alcanzable desde internet, ni desde la VLAN de invitados, ni desde toda la oficina por costumbre. Eso se arregla con una regla, no con una ventana de mantenimiento.

Y la limitación honesta del método: estas líneas contestan sobre esa máquina. La pregunta que importa es sobre todas. El salto de una máquina al parque entero es donde se ve si tienes un inventario que contesta o una hoja de cálculo que alguien actualizó en marzo.

La ventana la abrió un campo de copia

La exposición de esta semana no la abrió un atacante ni un fallo de diseño del kernel. La abrió un campo de copia en un correo electrónico. Un procedimiento de divulgación coordinada, que existe precisamente para que los detalles no salgan antes que el arreglo, se saltó solo por un destinatario de más.

Al estudio de referencia sobre por qué se caen los servicios grandes le pasa algo parecido: en dos de los tres servicios analizados, el error del operador es la primera causa de caída, y más de la mitad de esos errores —en un caso, casi todos— fueron errores de configuración. Aquí no se ha caído nada, pero la forma es la misma. Los procesos los ejecutan personas, y una persona se puede equivocar en el campo de destino.

Lo que sí se diseña es lo que viene después. Empieza por un inventario que contesta: no una lista de activos, sino una fuente de verdad que sepa qué kernel arranca cada nodo y qué servicios escuchan en qué puerto. Nosotros llevamos NetBox para eso y Zabbix con SmokePing para la telemetría; lo que importa no es la herramienta, es que «¿cuántas máquinas tienen esto?» se conteste consultando algo en lugar de preguntando a alguien. Sigue por la exposición, que es el único control que no depende de que exista un parche: el puerto que no es alcanzable no te obliga a correr, y decidir quién alcanza qué es trabajo de ciberseguridad y de Zero Trust —nadie llega a un servicio por estar dentro de la oficina, sino porque le corresponde—.

Y termina en lo único de los tres que no se automatiza: alguien que esté leyendo el canal de tu distribución cuando el arreglo aparezca, decida si esta noche toca o no toca, y deje escrito por qué. Eso es lo que vendemos como soporte IT 24x7, y lo vendemos con el límite por delante: no existe un escáner que vea lo que no tiene número, y nosotros tampoco lo tenemos. Lo que se puede sostener es la guardia, y que a las dos de la madrugada haya alguien que distinga entre lo que puede esperar al martes y lo que no.

La pregunta incómoda

No es «¿tengo ksmbd?». Esa se contesta en treinta segundos y con bastante probabilidad con un no. La pregunta incómoda es cuánto tardó tu organización en contestarla sin un CVE que pegar en un buscador. Si la respuesta es «aún no lo sé», el hueco no está en SMB: está en que tu capacidad de decir algo sobre tu propio parque depende de que alguien de fuera emita un número.

Ya nos topamos con el mismo hueco cuando contamos que las versiones corregidas de un aviso no se corresponden con ninguna rama que arranque un nodo Proxmox: el boletín te dice que el fallo existe, no si el binario que tú arrancas lo lleva. Y cuando el arreglo llegue, llegará con su propio coste, porque ya vimos que parchear el kernel es reiniciar, y reiniciar borra la prueba. Esta vez ni siquiera hay boletín: hay seis correos que salieron por la puerta de al lado.

Si quieres que miremos contigo qué escucha hoy en el 445 de tu red, quién tiene consola en los servidores donde importa y cuánto tardas en contestar la siguiente pregunta de este tipo, hablamos. El entregable es una lista, no un proyecto.

Fuentes. La cronología (informe de ConnMan el 20 de octubre de 2026 a las 00:17 UTC; cinco informes del kernel el 21 de octubre al equipo de seguridad y, por error, a listas públicas; cobertura y respuesta de Greg Kroah-Hartman el 22 de octubre), los seis identificadores ZDI-CAN con sus puntuaciones y estado de arreglo, la respuesta de Namjae Jeon sobre el commit 68f410faedaf, la rama de trabajo de Stefan Metzmacher para el ciclo 7.5, la fecha límite de divulgación del 18 de febrero de 2027 y los resultados de explotación con skb_zerocopy —root verificado en AlmaLinux 8, 9 y 10, CloudLinux 9 y 10, Debian 12 y 13 y Ubuntu 24.04 y 26.04, esquivando el arreglo de Dirty Frag (CVE-2026-43284)— proceden de Phoronix, TuxCare y Security Online. TuxCare comercializa parcheo del kernel sin reinicio: su interés comercial queda declarado, igual que el nuestro. La política de asignación de CVE y las dos citas proceden de la documentación del kernel; la descripción de ksmbd, el reparto entre kernel y espacio de usuario, la opción «SMB3 server support (EXPERIMENTAL)» y los dialectos soportados, de la documentación de ksmbd. Que Red Hat no construye ni distribuye ksmbd está publicado en su base de conocimiento. La existencia de una tabla de operaciones SMB1 con su manejador de negociación en ksmbd es comprobable en el propio código del kernel (fs/smb/server/smb_common.c). El estudio sobre causas de caída es Oppenheimer, Ganapathi y Patterson, «Why Do Internet Services Fail, and What Can Be Done About It?» (USENIX USITS, 2003). La lectura de que el fallo local importa según quién tenga consola, la advertencia sobre las trampas de cada comando de comprobación, la tesis de que el número es un recibo y no un aviso, y la lectura del cambio de tabla de operaciones son criterio nuestro, no afirmaciones de las fuentes citadas. everyWAN presta servicios gestionados de soporte y seguridad: el conflicto de interés queda declarado. Foto de portada: «Front of server racks at NERSC», de Derrick Coetzee, Wikimedia Commons, CC0 1.0.