Los informes filtrados sobre el núcleo de Linux incluyen dos errores de ksmbd y un exploit de root que burla la corrección «Dirty Frag Fix»

La versión resumida

Ir a la versión completa ↓

Qué ocurrió: Los días 20 y 21 de octubre de 2026 (UTC), la Zero Day Initiative (ZDI) de Trend Micro envió seis informes de vulnerabilidades al equipo de seguridad del núcleo y, por error, a listas de correo públicas, entre ellas LKML y netdev. Cinco de ellas son errores del núcleo y una se encuentra en ConnMan, un gestor de red del espacio de usuario. Ninguna incluía un parche, ninguna tiene aún un CVE y tres incluían el código fuente completo de la prueba de concepto (PoC). Phoronix se hizo eco de la noticia el 22 de octubre. Ir a esta sección →

La que realmente importa:ZDI-CAN-33367 es un fallo en la función auxiliar de red skb_zerocopy que permite a un usuario local sin privilegios escribir en la caché de páginas de un archivo al que solo tiene acceso de lectura. Pertenece a la misma clase que «Dirty Pipe» y está a un paso de obtener privilegios de root. TuxCare lo reprodujo internamente hasta conseguir un shell de root; este fallo elude la corrección de mayo para «Dirty Frag» (CVE-2026-43284) y, cuando se hicieron públicos los informes, aún no se había incorporado ninguna corrección en el código fuente original ni se había incluido en el núcleo de ninguna distribución. Así que este sí que fue un «zero day». Ir a esta sección →

Quiénes se ven afectados: En las pruebas realizadas por TuxCare, el exploit consiguió privilegios de root en AlmaLinux 8, 9 y 10, CloudLinux 9 y 10, Debian 12 y 13, y Ubuntu 24.04 y 26.04, superando además las restricciones de AppArmor de Ubuntu. Los núcleos de CentOS 6 y 7 no son vulnerables. Aún no se han probado CloudLinux 8 —que compila todos los módulos que necesita el exploit— ni Ubuntu 22.04. Ir a esta sección →

¿Qué hay de las vulnerabilidades 9.0 ksmbd? Ambas requieren que el servidor SMB integrado en el núcleo esté en funcionamiento, y este permanece desactivado a menos que un administrador lo configure deliberadamente. Las pruebas de concepto (PoC) públicas muestran una fuga de memoria en el montón del núcleo y bloqueos, en lugar de la ejecución de código, aunque eso no descarta que pueda haber consecuencias más graves. Ir a esta sección →

Situación actual: Todavía no hay ningún CVE para ZDI-CAN-33367. La corrección del desarrollador original ha sido aceptada en el árbol de redes del núcleo, pero aún no ha llegado a la rama principal. AlmaLinux 9 ya ha lanzado un núcleo corregido, mientras que AlmaLinux 10 aún no lo ha hecho. El parche de KernelCare, que no requiere reinicio, ya está disponible para EL10 y EL9; el de EL8 está listo para su lanzamiento, y se está trabajando en las versiones para Debian y Ubuntu. A fecha de 27 de octubre, no se ha informado de ningún caso de explotación en la red. Ir a esta sección →

Qué hacer hoy: Comprueba si los espacios de nombres de usuario sin privilegios están activados y desactívalos en los servidores que no los necesiten. A 0 Esto significa que no se pueden crear nuevos espacios de nombres de usuario, lo que debería bloquear la prueba de concepto pública:

sysctl user.max_user_namespaces

Ir a esta sección →

Los fallos de escalada de privilegios locales suelen dejarse para la semana que viene. La idea es que primero hay que conseguir un shell, y si ya lo tienen, entonces hay problemas más graves.

Esa lógica no se sostiene en los servidores en los que suele ejecutarse KernelCare. Un servidor de alojamiento compartido con 300 cuentas de cPanel tiene, por diseño, 300 usuarios locales, y cada uno de ellos puede ejecutar PHP o una tarea cron. Un ejecutor de CI ejecuta lo que le indique una solicitud de incorporación de cambios. Un nodo de inicio de sesión universitario existe para proporcionar shells. En todos estos casos, «usuario local» simplemente significa «cliente» o «tarea», y una escritura válida en la caché de la página puede otorgar privilegios de root a cualquiera de ellos.

Ese es precisamente el problema con ZDI-CAN-33367. El informe, el análisis y el código fuente de la demostración de concepto (PoC) se publicaron en las listas de correo públicas del kernel antes de que existiera una corrección. Normalmente, primero se publica el parche y después se dan a conocer los detalles. Esta vez ocurrió al revés.

La propia guía del núcleo para informar de fallos de seguridad pide a quienes los comuniquen que los envíen de forma privada a los responsables del mantenimiento de los subsistemas y al equipo de seguridad del núcleo, y no a una lista pública, y que no faciliten ningún código de reproducción. De esta forma, se puede preparar una corrección antes de que nadie más vea los detalles. ZDI suele funcionar de la misma manera. Su política de divulgación concede a los proveedores 120 días para publicar un parche antes de que los detalles se hagan públicos, y su próxima lista de avisos indica el 18 de febrero de 2027 como fecha límite para los cinco informes sobre el núcleo.

El informe sobre ConnMan se publicó primero en la lista pública de ConnMan, a las 00:17 UTC del 20 de octubre. La propia lista de ZDI lo fecha el 19 de octubre, que es cuando se envió según la hora de EE. UU. Los cinco informes sobre el núcleo, incluido el ZDI-CAN-33367, llegaron a continuación la tarde del 21 de octubre (UTC), con copia al equipo de seguridad del núcleo y también a LKML, netdev, linux-cifs, dri-devel y linux-nvme. Greg Kroah-Hartman y otros mantenedores respondieron que los informes ya eran públicos y que habían llegado sin parches. Tres de los seis incluyen una descripción detallada y el código fuente completo de la prueba de concepto (PoC). Dos informes del núcleo no tienen nada público más allá del título, y el último ni siquiera es un error del núcleo.

Por extraño que parezca, el fallo con la puntuación más baja del núcleo de la lista es aquel al que esta entrada dedica más tiempo. Una puntuación CVSS base describe el propio fallo. No refleja si ya se ha hecho público un código de explotación que funcione, y en el caso de ZDI-CAN-33367, sí que es así. En los equipos en los que se dan las condiciones previas para la explotación, eso es más importante que uno o dos puntos de puntuación.

Ninguna de ellas tiene aún un CVE. Puede parecer un mero trámite burocrático, pero muchos escáneres y paneles de control de parches se basan exclusivamente en los identificadores CVE, por lo que es posible que estos informes no aparezcan en ellos por el momento. Es recomendable complementar tus herramientas habituales con comprobaciones manuales y actualizaciones de los proveedores hasta que existan dichos identificadores.

skb_zerocopy() traslada los datos de los paquetes entre los búferes de los sockets pasando referencias a las mismas páginas de memoria, en lugar de copiar bytes. Esto es fantástico para el rendimiento. También es el tipo de atajo que aparece una y otra vez en los errores de la caché de páginas, en los que una referencia a una página que pertenece a un archivo acaba en algún lugar donde se puede escribir.

Dirty Pipe lo consiguió a través de los canales de comunicación en 2022. Copy Fail lo hizo a través del socket criptográfico AF_ALG en abril de 2026. En mayo, Dirty Frag (CVE-2026-43284) lo hizo a través de ESP, la capa IPsec, que descifraba los paquetes in situ incluso cuando sus páginas pertenecían a un archivo. ZDI-CAN-33367 es una secuela de este último.

La corrección «Dirty Frag» añadió un mecanismo de protección. Cuando los datos de los paquetes proceden de páginas que no son propiedad exclusiva del núcleo, se les asigna un indicador denominado SKBFL_SHARED_FRAG, y ESP comprueba ese indicador y realiza una copia privada antes de descifrar. skb_zerocopy() transfiere esas mismas páginas a un nuevo búfer, pero no transfiere el indicador. La protección nunca se activa, ESP descifra in situ y la escritura se almacena en la caché de páginas de un archivo que el atacante solo puede leer. El error subyacente se remonta a la operación de commit af2806f8f90a, que presentó skb_zerocopy() en el núcleo 3.14.

Esto tiene una consecuencia incómoda. AlmaLinux 8, 9 y 10 incluyen la corrección «Dirty Frag», tal y como confirmó TuxCare en los registros de cambios del núcleo de AlmaLinux, y, aun así, siguen siendo vulnerables. Un panel de parches que muestre CVE-2026-43284 como resuelto no aporta ninguna información sobre este error.

Al igual que en «Dirty Pipe», se trata de una escritura pura en la caché de páginas. Los procesos que leen o ejecutan el archivo posteriormente obtienen la versión del atacante, y tanto en «Dirty Pipe» como en «Copy Fail» esos cambios nunca llegaron al archivo en disco, lo que dificultó el análisis forense. Dirígelo a un binario setuid o /etc/passwd y conseguir privilegios de root es cuestión de un paso. El exploit no necesita ninguna capacidad especial ni una fuga de KASLR para lograrlo.

La demostración de concepto publicada tiene una lista de requisitos específica. Necesita espacios de nombres de usuario sin privilegios, que son la forma habitual en que un proceso sin privilegios obtiene derechos de administrador de red dentro de su propio entorno aislado. Además, se basa en módulos que se cargan automáticamente cuando se solicitan: nfnetlink_queue, nft_queue, nlmon, cls_u32, act_pedit, act_mirred y esp4, además de los módulos criptográficos que hay detrás de un cifrado ESP que no utiliza AEAD. El núcleo 6.1 de Debian 12 requiere una ruta ligeramente diferente para introducir páginas de archivo en un paquete, pero el exploit sigue funcionando en ese caso. Esa lista describe el exploit público, no todas las rutas posibles hacia el fallo, pero es lo que hace posible la mitigación, y se trata con más detalle más adelante.

El responsable de Netdev, Eric Dumazet, respondió al informe indicando que otra fuente había enviado el mismo error, junto con un parche, una semana antes, y que la corrección estaría disponible en breve. El 22 de octubre, ese parche se publicó en Netdev. Se trata de un cambio de una sola línea que hace que skb_zerocopy() copie el indicador de página compartida, y se ha enviado con copia al equipo de la rama estable.  Desde entonces, se ha aceptado en el árbol de redes como commit `79dc34beb1fd`, pero aún no ha llegado a la rama principal. En cualquier caso, una corrección en el árbol de un responsable no indica en qué momento los kernels corregidos llegarán a tus hosts. Una corrección de origen aún tiene que incorporarse al kernel de la distribución, luego convertirse en un paquete y, a continuación, aplicarse mediante un reinicio o un parche sin reinicio en cada servidor expuesto; además, el PoC ya se encuentra en un archivo público.

TuxCare recompiló el PoC público para cada uno de los objetivos que se indican a continuación y lo ejecutó. «Root verificado» significa que terminó con un shell con uid 0.

Las dos versiones anteriores son seguras por diferentes motivos. El núcleo 2.6.32 de CentOS 6 es anterior a skb_zerocopy() por completo, así que no hay nada que se pueda aprovechar. El núcleo 3.10 de CentOS 7 lo incluye, pero su código ESP siempre crea una copia privada de los paquetes no lineales antes de descifrarlos. El atajo «in-place» llegó al código fuente en la versión 4.11 y nunca se incorporó a EL7; además, los espacios de nombres de usuario sin privilegios están desactivados por defecto en esa versión.

Aún no se han probado Ubuntu 22.04 y varias líneas de kernel independientes, entre las que se incluyen los kernels EL y ELS, los kernels AlmaLinux ESU y FIPS, Oracle UEK, los kernels «cloud» y HWE, y el kernel de CloudLinux 7. Tampoco se ha probado CloudLinux 8, pero su kernel compila todos los módulos que necesita el exploit público. Los núcleos corregidos de CloudLinux 7h y 8 (4.18.0-553.177.1.lve.1) se encuentran en fase beta. Considérenlos todos como potencialmente afectados hasta que se hayan comprobado.

A partir de Ubuntu 24.04, se aplican restricciones de AppArmor a los espacios de nombres de usuario sin privilegios, controlados por kernel.apparmor_restrict_unprivileged_userns. Esto no impidió que se llevara a cabo este exploit. La prueba de concepto (PoC) lo elude ejecutándose a través del perfil de AppArmor de un paquete de lanzamiento de contenedores al que se le permite crear espacios de nombres de usuario. No lo consideres una medida de mitigación.

ZDI otorga a ambos informes de ksmbd una puntuación de 9,0 y los clasifica como fallos que permiten la ejecución remota de código, lo que explica por qué han acaparado los titulares. Las pruebas de concepto (PoC) públicas demuestran la divulgación de memoria del núcleo y fallos del sistema, más que la ejecución de código. Se trata de problemas de seguridad reales por sí mismos, y los resultados publicados no muestran todo el alcance de lo que un atacante podría hacer. ZDI también señala una ruta de escritura fuera de límites para ZDI-CAN-33774 que no aparece en el material público.

Lo que limita el alcance del daño es la exposición. Ambos fallos residen en ksmbd, el servidor SMB integrado en el núcleo. Este es independiente de Samba, el servidor SMB del espacio de usuario que ejecutan la mayoría de los servidores de archivos de Linux, y los servidores que comparten archivos únicamente a través de Samba no están expuestos a estos fallos.

AlmaLinux y CloudLinux 9 y 10 no compilan ksmbd en absoluto. Debian y Ubuntu sí lo compilan, pero es una opción que hay que activar. Solo se ejecuta después de que un administrador lo instale ksmbd-tools, que no aparece por defecto, y inicia el ksmbd servicio. El ZDI-CAN-33549 añade más requisitos. Requiere SMB Direct a través de un dispositivo de red RDMA y un recurso compartido en el que se pueda escribir, accesible mediante un inicio de sesión o un acceso de invitado. Ubuntu incluye SMB Direct de serie, mientras que Debian no, y el hardware RDMA es poco habitual en los servidores de alojamiento.

Si ejecutas ksmbd, tómate en serio el fallo de seguridad ZDI-CAN-33774. Es accesible a través de la red antes de iniciar sesión, filtra 28 bytes del montón del kernel cada vez y puede provocar un fallo del sistema. Namjae Jeon, responsable del mantenimiento de ksmbd respondió que ya está corregido en su árbol como confirmar 68f410faedaf, que aún no se ha incorporado a la rama principal. Si systemctl is-active ksmbd indica que está inactivo y lsmod no incluye ksmbd, eso es una buena señal de que el servidor no está en marcha, pero comprueba que ningún otro proceso del host lo haya iniciado antes de descartarlo. Si está activo y no hay ningún proceso que dependa del recurso compartido, deténlo con systemctl disable --now ksmbd. Si necesitas el recurso compartido, manténlo fuera de las redes no fiables hasta que estén disponibles los núcleos corregidos.

El resto del montón

ZDI-CAN-34068 es una escritura fuera de límites en vmwgfx, el controlador de la GPU virtual de VMware, clasificada como una escalada de privilegios local. ZDI-CAN-34076 es una fuga de memoria no inicializada en nvmet, el destino de NVMe over Fabrics. Ambos se han hecho públicos únicamente con sus títulos. Al no disponerse de detalles técnicos, no hay nada concreto que comprobar o mitigar, por lo que no se prevé tomar ninguna medida hasta que se publique más información.

ZDI-CAN-32005 se encuentra en ConnMan, un gestor de red del espacio de usuario. No se trata de un error del núcleo, por lo que queda fuera del ámbito de los parches de KernelCare. Si utilizas ConnMan, mantente atento a las actualizaciones a través de tus canales habituales de paquetes.

Ninguna de las soluciones de mitigación que se indican a continuación se ha validado aún internamente con respecto a la prueba de concepto (PoC). Prueba primero cada una de ellas en un servidor de pruebas para averiguar qué elementos dependen de ellas, y no consideres ninguna de ellas como sustituto de una solución definitiva.

La opción principal es desactivar los espacios de nombres de usuario sin privilegios. Configuración user.max_user_namespaces a 0 impide que se creen nuevos espacios de nombres de usuario, lo que debería bloquear la demostración de concepto pública, ya que esta depende de la creación de uno. A diferencia de la restricción de AppArmor de Ubuntu, se trata de un límite estricto del núcleo que ningún perfil de AppArmor puede eludir:

echo 'user.max_user_namespaces = 0' > /etc/sysctl.d/99-zdi-33367.conf
sysctl --system

Los espacios de nombres que ya existen se mantienen tal cual, por lo que todo lo que ya se esté ejecutando dentro de uno de ellos seguirá funcionando. El coste también es real. Los contenedores sin raíz, las aplicaciones Flatpak y algunos entornos aislados de los navegadores dependen de los espacios de nombres de usuario y pueden dejar de funcionar.

La opción más ligera desactiva dos de los módulos menos habituales en los que se basa la demostración de concepto pública, nlmon y act_pedit, que se carga a través del mecanismo habitual de los módulos:

printf 'install nlmon /bin/false\ninstall act_pedit /bin/false\n' > /etc/modprobe.d/zdi-33367.conf
lsmod | grep -E '^(nlmon|act_pedit) '

En lsmod Esta línea solo te indica si alguno de los módulos está cargado en este momento. Si aparece alguno, la nueva regla no lo descargará. Comprueba que nada dependa de él y, a continuación, descarga ese módulo con modprobe -r, o programa un reinicio. Sin embargo, un resultado vacío no prueba que el bloque esté en su sitio. Ejecuta modprobe -n -v nlmon y modprobe -n -v act_pedit, y comprueba que ambos impriman el install /bin/false línea. Esto confirma la configuración del módulo, no que se haya detenido el ataque. Son pocos los servidores que utilizan nlmon o el pedit acción en tc, pero compruébalo antes de dar nada por sentado. Además, bloquear estos dos elementos puede que no elimine todas las vías de acceso al error. Lo único que se sabe es que el PoC público los necesita. El PoC necesita esp4 también, así que si un servidor no utiliza IPsec y lo has bloqueado esp4 Para «Dirty Frag», de mayo, comprueba que el bloque siga en su sitio.

Desactivar los espacios de nombres de usuario es la opción principal, así que empieza por ahí en cualquier servidor que pueda funcionar sin ellos. Comprueba primero qué se ejecuta en el servidor. En servidores web, de correo, de bases de datos y de alojamiento compartido suele ser una opción práctica, siempre y cuando no se utilicen contenedores sin privilegios de root ni entornos aislados (sandboxing). En ejecutores de CI, servidores de compilación y estaciones de trabajo de desarrolladores que dependen de los espacios de nombres de usuario, bloquear los dos módulos es una solución alternativa menos disruptiva, pero puede dejar abiertas otras vías para que se produzca el error. Da prioridad a esos servidores cuando se publique un parche que no requiera reinicio.

Comprobar un servidor en menos de un minuto

Tres comandos resuelven la mayoría de las dudas:

sysctl user.max_user_namespaces
systemctl is-active ksmbd
lsmod | grep -E '^(ksmbd|nlmon|act_pedit) '

A 0 Desde el principio, los nuevos espacios de nombres de usuario están desactivados, lo que debería bloquear la vía de acceso del exploit público. inactive La segunda línea indica que ksmbd no se está ejecutando, y la tercera confirma si el ksmbd El módulo o cualquiera de los dos módulos bloqueables está cargado en este momento. En Ubuntu 24.04 y versiones posteriores, no le des demasiada importancia a sysctl kernel.apparmor_restrict_unprivileged_userns. La prueba de concepto superó esa restricción durante las pruebas. Se trata de indicadores rápidos, no de una prueba de seguridad completa. En el caso de una flota, ejecuta las mismas líneas a través de cualquier herramienta que ya gestione tus comandos ad hoc, ya sea Ansible, Salt o simplemente SSH en bucle.

Ya está disponible el parche sin necesidad de reinicio de KernelCare para ZDI-CAN-33367 para los núcleos EL10 y EL9 en AlmaLinux, CloudLinux, RHEL, Oracle Linux y Rocky Linux. Se basa en la versión candidata a corrección del proyecto original, y TuxCare ha verificado que detiene el exploit público. El parche para EL10 se encuentra tanto en el canal de producción como en el de ePortal. El parche para EL9 está en el canal de producción, pero aún no en ePortal. El parche para EL8 está listo para su lanzamiento, y se está trabajando en las versiones para Debian y Ubuntu, aunque aún no hay una fecha prevista. Los núcleos EL6 y EL7 no son vulnerables, por lo que no recibirán un parche sin reinicio para este fallo.

En EL9 y EL10, los servidores con actualizaciones automáticas de KernelCare obtienen el parche según su calendario habitual, o bien puedes descargarlo inmediatamente con el comando `kcarectl –update`. No es necesario reiniciar el sistema, lo cual es más importante de lo habitual en este caso, ya que el bloque de módulos mencionado anteriormente puede requerirlo. Al no haberse asignado ningún identificador CVE, el rastreador CVE de TuxCare no muestra hoy nada relacionado con estos informes. Una vez que existan los identificadores, ahí es donde aparecerá el estado de los parches sin necesidad de reinicio para cada distribución.

Consigue hoy mismo KernelCare Enterprise →

Por qué una filtración como esta cambia las reglas del juego

La divulgación coordinada tiene como objetivo dar ventaja a los defensores, y esta semana esa ventaja fue nula.

En el marco de la divulgación coordinada, los responsables del mantenimiento y las distribuciones suelen disponer de tiempo para preparar correcciones antes de que se hagan públicos los detalles técnicos o el código del exploit. En este caso, el orden se invirtió: primero se desarrolló el exploit y después se aplicó la corrección. Ese intervalo entre la publicación del exploit y la aplicación del parche en los equipos es precisamente lo que todo proceso de aplicación de parches intenta reducir al mínimo, y en el caso de ZDI-CAN-33367 se abrió antes de que nadie pudiera actuar.

La corrección en el código fuente no tardará mucho en llegar, y ya se encuentra en el árbol de redes. Otra persona detectó este error una semana antes y envió un parche, lo que da una idea de cuánta gente está revisando minuciosamente el mismo código del núcleo en este momento. Cabe esperar más coincidencias como esta y más errores que salgan a la luz antes de que un núcleo estable incorpore la corrección.

Así que revisa hoy mismo los espacios de nombres de usuario y desactívalos allí donde no sean necesarios. Averigua si alguien ha activado ksmbd y se ha olvidado de ello. A continuación, espera a que esa corrección llegue a los núcleos de tu distribución y calcula cuánto tardarás en aplicarla a todos los hosts expuestos —ya sea mediante un parche sin reinicio o reiniciando el sistema, lo que tu parque de equipos pueda tolerar realmente—.

Consigue hoy mismo KernelCare Enterprise →

Cómo transcurrió la semana

Fuentes

Las fuentes principales de esta entrada son los informes originales de ZDI y las respuestas de los responsables del mantenimiento en las listas de correo públicas, entre las que se incluyen el informe ZDI-CAN-33367, la respuesta de Eric Dumazet, el parche skb_zerocopy, el hilo ZDI-CAN-33774, la confirmación de la corrección de ksmbd y el informe de ConnMan, además de la lista de próximos avisos de seguridad de ZDI, la cobertura de Phoronix, la guía de notificación de fallos de seguridad del núcleo, la política de divulgación de ZDI, la documentación del ksmbd del núcleo, el artículo de Max Kellermann sobre «Dirty Pipe», la divulgación de «Copy Fail», la entrada del NVD sobre «Dirty Frag» y las propias pruebas de TuxCare en las distribuciones mencionadas anteriormente.