Fallo previo a la autenticación en Linux KSMBD: RCE CVSS 9.0 según ZDI, aún sin corrección publicada (ZDI-CAN-33774)

Resumen

• ZDI-CAN-33774: una condición de carrera previa a la autenticación en la selección de manejadores de protocolo de KSMBD, activada por una sola escritura TCP que encadena una ráfaga de paquetes SMB1 antes de un paquete SMB2.
• ZDI-CAN-33549: un desbordamiento inferior de entero en la ruta SMB Direct (RDMA) de KSMBD.
• Todo host que ejecute KSMBD con el puerto TCP 445 accesible para interlocutores no confiables está expuesto. ZDI-CAN-33774 no necesita autenticación. ZDI-CAN-33549 requiere además negociar SMB Direct, una interfaz compatible con RDMA y un recurso compartido escribible.
• El código público de prueba de concepto, publicado con los informes en las listas públicas del kernel, demuestra una fuga de 28 bytes de memoria del heap del kernel por intento antes de la autenticación y una caída del kernel, no ejecución de código. ZDI califica ambos fallos como ejecución remota de código y describe una ruta de escritura para ZDI-CAN-33774, pero nada público demuestra que llegue a ejecutar código. No se ha comunicado explotación en ataques reales a fecha del 24 de octubre de 2026 (Sysdig).
• Aún no hay una corrección que instalar. La de ZDI-CAN-33774 se integró en el árbol de desarrollo principal el 20 de octubre de 2026, pero ningún kernel publicado la contiene; ZDI-CAN-33549 tiene un parche propuesto sin corrección publicada confirmada, y ninguno tiene identificador CVE. Deje de exponer KSMBD: desactive el servicio donde no sea necesario, mantenga el puerto 445 fuera de redes no confiables y deje SMB Direct desactivado salvo que lo necesite.

Zero Day Initiative de Trend Micro califica ambos fallos con CVSS 9.0 y reconoce a Hyeontae Lee como descubridor de los dos.

¿Estoy afectado?

ZDI-CAN-33774 le expone a la fuga y caída demostradas si se cumplen las dos primeras condiciones; ZDI-CAN-33549 requiere además la tercera:

• Su compilación del kernel incluye KSMBD y el servicio está en ejecución. systemctl status ksmbd indica el estado del servicio; lsmod | grep ksmbd indica si el módulo del kernel está cargado. Que esté cargado no basta para establecer exposición: utilice el comando ss siguiente para comprobar si hay un servicio a la escucha en el puerto 445 y confirmar que es KSMBD.
• El puerto TCP 445 es accesible desde Internet, redes de inquilinos o cualquier interlocutor en el que no confíe plenamente.
• Solo para ZDI-CAN-33549: la conexión puede negociar SMB Direct mediante una interfaz compatible con RDMA, de hardware o con el controlador software rxe, y existe un recurso compartido KSMBD escribible.

Los dos fallos difieren en sus requisitos y su estado:

Compruebe qué ejecuta:

systemctl status ksmbd          # is the KSMBD service running?
lsmod | grep ksmbd              # is the module loaded?
ss -tlnp | grep :445            # is the SMB port listening, and on which address?

Dónde se ejecuta realmente KSMBD:

¿Cómo lo corrijo?

No hay una corrección publicada que instalar para ninguno de los fallos, por lo que debe eliminar la exposición en lugar de aplicar un parche:

1. Detenga y desactive KSMBD donde no necesite servir SMB desde el kernel: systemctl stop ksmbd && systemctl disable ksmbd. Contrapartida: elimina por completo el servicio de archivos.
2. Donde deba mantener el servicio, restrinja el puerto 445 a redes cuyos hosts sean confiables, tanto en el firewall del host como en los perimetrales. Contrapartida: el servicio permanece activo, pero solo interlocutores confiables pueden alcanzar los fallos. Cualquier ruta accesible para usuarios no confiables deja abierto ZDI-CAN-33774, porque no necesita autenticación.
3. Deje SMB Direct y RDMA desactivados salvo que los utilice específicamente, lo que cierra ZDI-CAN-33549. Contrapartida: no hace nada contra ZDI-CAN-33774, el fallo previo a la autenticación.

Vigile la publicación de kernels corregidos en lugar de adivinar fechas. Las correcciones que llegan al árbol principal suelen tardar semanas en alcanzar las ramas estables y después los kernels de distribuciones, y el proyecto del kernel solo asigna CVE cuando hay una corrección en el árbol estable. Cuando su distribución publique un kernel que incluya el commit 68f410faedaf («ksmbd: esperar a la negociación antes de recibir otra PDU»), ZDI-CAN-33774 estará cerrado en ese host. Para ZDI-CAN-33549, pregunte al proveedor si incluye el parche del 23 de octubre, «smb: smbdirect: corregir el desbordamiento inferior de longitud de búfer en transferencias RDMA».

¿Cuál es la causa raíz?

El hilo de recepción de KSMBD podía leer la siguiente unidad de datos de protocolo antes de terminar el proceso de negociación. Así, una solicitud SMB2 encadenada podía sustituir la tabla de manejadores de la conexión mientras un proceso aún gestionaba una solicitud SMB1 anterior y más corta.

El propio commit de corrección del mantenedor, 68f410faedaf, describe exactamente el mecanismo:

El hilo de recepción encola una solicitud y puede leer la siguiente PDU antes de que termine el proceso de negociación. Mientras need_neg está establecido, la siguiente PDU puede hacer que ksmbd_init_smb_server() sustituya conn->ops. Por tanto, una solicitud SMB2 encadenada puede hacer que el proceso gestione una solicitud SMB1 anterior y más corta con operaciones SMB2 y lea fuera de su búfer.

Una negociación multiprotocolo SMB1 puede ir seguida de un SMB2 NEGOTIATE que cambie de nuevo conn->ops.

El mecanismo, paso a paso:

• conn->ops es la tabla de manejadores de la conexión: el conjunto de punteros a funciones que convierte un comando SMB decodificado en una acción. SMB1 y SMB2 tienen disposiciones de comandos diferentes, por lo que el servidor asigna una tabla u otra durante la negociación, cuando need_neg está establecido.
• Esa asignación ocurre en ksmbd_init_smb_server(). Volver a ejecutarla durante una conexión sustituye conn->ops mientras aún puede estar ejecutándose trabajo encolado con la tabla anterior.
• Una solicitud encadenada, varias unidades de datos de protocolo dentro de una escritura TCP, fuerza el solapamiento: el hilo de recepción lee el paquete SMB2 y vuelve a negociar antes de que termine el proceso encolado para el paquete SMB1 anterior y más corto.
• El proceso aplica entonces la lógica del manejador SMB2 a un búfer de tamaño SMB1 y lee más allá de su final.

Para ZDI-CAN-33549, el informe describe un desbordamiento inferior de entero en la ruta SMB Direct: un cliente proporciona descriptores de búfer RDMA cuyo primero es más largo que el payload declarado, lo que hace desbordar el contador de tamaño del servidor. Una copia de memoria posterior supera entonces el final de un búfer reservado.

¿Cómo se explota?

No se ha comunicado explotación en ataques reales, y la ruta de ataque es pública en los propios informes, publicados en las listas del kernel con código fuente de prueba de concepto:

1. El atacante se conecta al puerto 445 de un host con KSMBD. Para ZDI-CAN-33774 no necesita autenticación, por lo que queda expuesto cualquier servidor que ejecute KSMBD en ese puerto.
2. Envía una escritura TCP que contiene una ráfaga de paquetes SMB1 cortos seguida de un paquete SMB2.
3. El hilo de recepción encola trabajo para los paquetes SMB1 y lee el paquete SMB2, que vuelve a negociar y sustituye conn->ops por la tabla de manejadores SMB2.
4. El proceso encolado gestiona la solicitud SMB1 anterior y más corta con operaciones SMB2 y lee fuera del búfer más corto.
5. La prueba de concepto pública demuestra una fuga de 28 bytes de memoria del heap del kernel por intento antes de la autenticación y una caída del kernel. El informe de ZDI también describe una ruta para escribir fuera del búfer una vez que el atacante accede a un recurso compartido, pero nada público demuestra que llegue a ejecutar código, según Sysdig.

Para ZDI-CAN-33549, el atacante es un cliente que negocia SMB Direct y proporciona descriptores de búfer RDMA manipulados; necesita una interfaz compatible con RDMA en el servidor, un recurso compartido escribible y el transporte SMB Direct, por lo que exige más condiciones que ZDI-CAN-33774.

¿Cómo se desarrolla el ataque?

Todo el ataque consiste en una escritura TCP encadenada que hace cambiar al servidor su tabla de manejadores bajo un proceso encolado.

La sincronización ausente está en C: nada obliga al hilo de recepción a esperar al proceso de negociación antes de leer la siguiente unidad de datos de protocolo.

¿Qué puede hacer un atacante?

Contra un host expuesto, el impacto demostrado públicamente es divulgación de memoria del kernel, 28 bytes de heap por intento antes de la autenticación, y una caída del kernel, que supone denegación de servicio para un servidor de archivos. ZDI califica ambos fallos con CVSS 9.0 como ejecución remota de código y su informe ZDI-CAN-33774 describe una ruta para escribir fuera del búfer tras obtener acceso a un recurso compartido, por lo que es plausible corrupción de memoria más allá de la fuga demostrada. Ninguna demostración pública la convierte en ejecución de código y no se ha comunicado uso en ataques reales.

Las condiciones de cada fallo:

• ZDI-CAN-33774: para activar la fuga y la caída, una compilación del kernel con KSMBD, el servicio ejecutándose y el puerto 445 accesible; no necesita cuenta ni recurso compartido. La ruta de escritura descrita por ZDI requiere además acceso a un recurso compartido.
• ZDI-CAN-33549: todo lo anterior, más SMB Direct negociado, una interfaz compatible con RDMA (hardware o controlador software rxe) y un recurso compartido escribible.
• Ninguno afecta a Samba en espacio de usuario (smbd), una base de código independiente que no comparte la ruta de selección del kernel de KSMBD.

¿Por qué funciona la corrección?

La corrección de ZDI-CAN-33774, commit 68f410faedaf del mantenedor de KSMBD Namjae Jeon, añade una espera a la ruta de recepción en fs/smb/server/server.c:

--- a/fs/smb/server/server.c
+++ b/fs/smb/server/server.c
@@ static int queue_ksmbd_work(struct ksmbd_conn *conn)
    struct ksmbd_work *work;
+   bool wait_for_neg = ksmbd_conn_new(conn) || ksmbd_conn_need_negotiate(conn);
    int err;
@@
    INIT_WORK(&work->work, handle_ksmbd_work);
    ksmbd_queue_work(work);
+   /* Negotiation can change conn->ops, finish it before reading another PDU. */
+   if (wait_for_neg)
+       wait_event(conn->req_running_q,
+              atomic_read(&conn->req_running) == 0);
    return 0;

Tras encolar trabajo en una conexión nueva o aún en negociación, el hilo de recepción espera ahora en conn->req_running_q hasta que terminen todas las solicitudes encoladas. La tabla de manejadores no puede sustituirse mientras un proceso siga gestionando una solicitud anterior, de modo que los datos SMB1 nunca se manejan con operaciones SMB2. El commit mantiene la semántica de need_neg. Su mensaje presenta el cambio como una forma de mantener estables las operaciones en ambas etapas de negociación.

La corrección es completa para esta carrera y responde a un informe anterior relacionado, con reconocimiento a ihopenre-eng. Quedan dos límites: reside en el árbol principal de desarrollo, integrada el 20 de octubre de 2026, por lo que ningún kernel publicado la incluye aún; y no modifica la ruta SMB Direct, de modo que ZDI-CAN-33549 requiere su parche independiente.

¿Cómo compruebo si he sufrido una intrusión?

No se ha comunicado explotación ni se han publicado indicadores de compromiso para ninguno de los fallos. Si ejecuta KSMBD expuesto a redes no confiables y quiere auditarlo:

• Revise los registros de conexiones y firewall del puerto 445 en busca de direcciones de origen inesperadas. Si hay capturas de paquetes, busque ráfagas de solicitudes seguidas de desconexiones bruscas; ese patrón por sí solo no demuestra explotación.
• Revise los registros del kernel buscando registros oops o panic que mencionen ksmbd o fs/smb/server, porque la PoC pública puede hacer caer el kernel.
• Trate la fuga de 28 bytes de heap por intento como una exposición real: cada intento revela contenido del heap del kernel, por lo que varios intentos contra un host expuesto podrían haber recolectado memoria incluso sin una caída. Si sospecha un compromiso, aplique la respuesta habitual a un incidente a nivel de kernel: aísle el host, rote todas sus credenciales y reconstruya desde una imagen conocida como válida.

Cronología

• 2026-09-30: el mantenedor de KSMBD Namjae Jeon escribe el commit 68f410faedaf, «ksmbd: esperar a la negociación antes de recibir otra PDU», con reconocimiento a ihopenre-eng, en respuesta a un informe anterior.
• 2026-10-20: el commit de corrección se integra en el árbol principal de desarrollo Linux (marca de tiempo del integrador: 20 de octubre, 23:55 UTC).
• 2026-10-21: ZDI divulga ZDI-CAN-33774 y ZDI-CAN-33549, ambos calificados con CVSS 9.0 y atribuidos a Hyeontae Lee, en las listas públicas del kernel sin parches adjuntos (marcas de tiempo UTC).
• 2026-10-21: el mantenedor de SMB Direct Stefan Metzmacher pide al informante probar la rama de desarrollo for-7.5/smbdirect como posible corrección de ZDI-CAN-33549.
• 2026-10-22: Namjae Jeon responde que el commit 68f410faedaf ya corrige la carrera.
• 2026-10-22: el mantenedor del kernel estable Greg Kroah-Hartman responde pidiendo parches en lugar de divulgaciones públicas.
• 2026-10-22: The Hacker News cubre las divulgaciones.
• 2026-10-23: Namjae Jeon publica un parche menor para el desbordamiento inferior de SMB Direct después de que Stefan Metzmacher recomiende una corrección mínima.
• 2026-10-23 a 25: AlmaLinux, CloudLinux y Sysdig publican análisis; la PoC pública se documenta como una fuga de 28 bytes del heap del kernel por intento antes de la autenticación y una caída, no ejecución de código.
• 2026-10-26: este artículo. No se ha comunicado explotación en ataques reales y ninguno de los fallos figura en el catálogo CISA KEV.

Preguntas frecuentes

¿Por qué estos fallos no tienen identificador CVE?

Según su política publicada, el proyecto del kernel Linux solo asigna números CVE después de que una corrección esté disponible en un kernel estable publicado. Ambos fallos se divulgaron en listas públicas antes de que ningún kernel publicado incluyera una corrección, por lo que se registran con sus identificadores ZDI-CAN. Los CVE deberían aparecer cuando los kernels estables incorporen las correcciones.

¿La PoC pública da ejecución remota de código a los atacantes?

No. Demuestra una fuga de 28 bytes del heap del kernel por intento antes de la autenticación y una caída del kernel. Las calificaciones CVSS 9.0 de ZDI tratan los fallos como ejecución remota de código y su informe ZDI-CAN-33774 describe una ruta para escribir fuera del búfer cuando el atacante accede a un recurso compartido, pero ninguna demostración pública muestra ejecución de código, según Sysdig.

¿Está afectado el kernel de mi distribución?

Solo si la distribución compila KSMBD y se ha iniciado el servicio. Red Hat Enterprise Linux no incluye KSMBD por defecto, los kernels AlmaLinux y CloudLinux 9 y 10 no lo compilan, y Debian y Ubuntu solo lo ejecutan tras instalar ksmbd-tools e iniciar el servicio. Deben auditarse los dispositivos NAS y servidores de almacenamiento que distribuyen kernels con KSMBD activado para servir archivos.

¿Están afectados los servidores Samba?

No. smbd de Samba en espacio de usuario es una implementación independiente que no comparte el código de selección del kernel de KSMBD. El software expuesto es KSMBD, el servidor SMB dentro del kernel, identificable con systemctl status ksmbd o lsmod | grep ksmbd.

¿Cuándo llegará una corrección a mi kernel?

La de ZDI-CAN-33774 llegó al árbol principal de desarrollo el 20 de octubre de 2026, y las correcciones de esa rama suelen tardar semanas en alcanzar las ramas estables y después los kernels de distribuciones. Para ZDI-CAN-33549, Stefan Metzmacher pidió inicialmente probar la rama for-7.5/smbdirect. Namjae Jeon publicó después un parche menor el 23 de octubre; eso no demuestra disponibilidad en el kernel publicado de su distribución. Consulte los avisos de su distribución para el commit 68f410faedaf (ZDI-CAN-33774) y el parche SMB Direct del 23 de octubre (ZDI-CAN-33549); confirme cada cobertura por separado.

¿Necesito SMB Direct para preocuparme por ambos fallos?

No. ZDI-CAN-33549 necesita SMB Direct, una interfaz RDMA y un recurso compartido escribible. ZDI-CAN-33774 no necesita nada de eso: es accesible para cualquier interlocutor no autenticado que alcance el puerto 445 de un host con KSMBD, por lo que su exposición debe eliminarse primero.

Encuentre servidores SMB expuestos antes que un atacante

Siga la guía de escaneo de red de Ostorlab: seleccione Nuevo escaneo → Red, introduzca sus direcciones o rangos IP, elija Escaneo completo de red e inicie el escaneo. Revise los hallazgos del puerto 445 y confirme localmente si el servicio es KSMBD o Samba en espacio de usuario. Restrinja los servicios KSMBD expuestos mientras espera un kernel corregido de su distribución.

Referencias

• Informe primario ZDI-CAN-33774, replicado por Openwall, con marca de tiempo UTC de divulgación del 21 de octubre y ruta de escritura descrita: https://lists.openwall.net/linux-kernel/2026/10/21/2694
• Discusión de Stefan Metzmacher sobre la rama SMB Direct y la corrección mínima, 23 de octubre: https://lists.openwall.net/linux-kernel/2026/10/23/739
• Parche adjunto de Namjae Jeon para el desbordamiento inferior SMB Direct, 23 de octubre: https://lists.openwall.net/linux-kernel/2026/10/23/971
• The Hacker News, «Dos fallos RCE CVSS 9.0 de Linux KSMBD divulgados en listas públicas antes de las correcciones del kernel», 22 de octubre de 2026, actualizado el 26 de octubre, con los mecanismos, respuestas de mantenedores, alcance de la PoC y estado de las distribuciones: https://thehackernews.com/2026/10/two-cvss-90-linux-ksmbd-rce-flaws.html (consultado el 26 de octubre de 2026)
• Próximos avisos ZDI, que enumeran ZDI-CAN-33774 y ZDI-CAN-33549 con CVSS 9.0, proveedor Linux, descubiertos por Hyeontae Lee: https://www.zerodayinitiative.com/advisories/upcoming/ (consultado el 26 de octubre de 2026)
• Informe ZDI de ZDI-CAN-33774 en las listas públicas del kernel: https://lore.kernel.org/lkml/BYAPR01MB383076AC412E19C48CFBEAE980662@BYAPR01MB3830.prod.exchangelabs.com/ (informe primario)
• Informe ZDI de ZDI-CAN-33549 en las listas públicas del kernel: https://lore.kernel.org/lkml/BYAPR01MB3830472B5702C089B0BBB77D80662@BYAPR01MB3830.prod.exchangelabs.com/ (informe primario)
• Commit de corrección 68f410faedaf, «ksmbd: esperar a la negociación antes de recibir otra PDU», en el árbol principal Linux, creado el 30 de septiembre de 2026, con marca de tiempo de integración del 20 de octubre de 2026: https://github.com/torvalds/linux/commit/68f410faedaf6ee74d81e574733c50ebcc1bd8ed (consultado el 26 de octubre de 2026)
• Sysdig sobre los seis informes del kernel de octubre, el alcance de la PoC y el estado de la corrección sin integrar: https://www.sysdig.com/blog/detecting-and-mitigating-zdi-can-33367-and-five-other-linux-flaws (referenciado mediante The Hacker News, 26 de octubre de 2026)
• AlmaLinux sobre los informes en listas públicas del kernel: https://almalinux.org/blog/2026-10-23-zdi-can-33367/ (referenciado mediante The Hacker News, 26 de octubre de 2026)
• CloudLinux sobre la PoC de KSMBD y el estado de compilación en distribuciones: https://blog.cloudlinux.com/zdi-can-33367 (referenciado mediante The Hacker News, 26 de octubre de 2026)
• Documento de solución Red Hat 6991749, KSMBD no incluido por defecto en RHEL: https://access.redhat.com/solutions/6991749 (referenciado mediante The Hacker News, 26 de octubre de 2026)
• Política de asignación CVE del kernel Linux, con emisión solo tras una corrección en el árbol estable: https://docs.kernel.org/process/cve.html (referenciado mediante The Hacker News, 26 de octubre de 2026)