Una vulnerabilidad en el núcleo de Linux de CIFSwitch permite obtener privilegios de root locales en cifs-utils

28 de mayo de 2026 – 7 minutos de lectura Chris DeMars, promotor sénior de desarrolladores

La versión resumida

¿Qué? Una nueva vulnerabilidad de escalada de privilegios locales en Linux, denominada CIFSwitch, aprovecha la falta de una comprobación por parte del núcleo en las descripciones de las claves cifs.spnego, junto con la confianza que el asistente cifs.upcall del espacio de usuario deposita en dichas descripciones. El resultado es un shell de root desde cualquier cuenta local sin privilegios en los hosts afectados. La ruta del código del núcleo ha estado latente desde 2007. En el momento de la publicación, aún no se le ha asignado ningún CVE.

Repercusión: Una demostración pública de viabilidad realizada por Asim Manizada ofrece a cualquier usuario local sin privilegios una vía fiable para obtener privilegios de root en los sistemas que cumplen los requisitos previos del exploit. El autor ha confirmado que la vulnerabilidad afecta a unas 30 combinaciones de distribuciones y ediciones.

Estado: Manizada reveló CIFSwitch en oss-security el 28 de mayo de 2026 tras un periodo de embargo en linux-distros. El fallo se notificó a los mantenedores de kernel/cifs el 16 de mayo, y la corrección del proyecto original (commit 3da1fdf4efbc) lleva más de una semana disponible públicamente y está en cola para la versión estable.

Gravedad: Confirmada de forma predeterminada en AlmaLinux 9.7, Rocky Linux 9 Workstation, CentOS Stream 9 GNOME, Linux Mint 21/22, Kali 2021 a 2026 (sin interfaz gráfica) y SLES 15 SP7/SAP. Vulnerable cuando cifs-utils se instala manualmente en Debian 11/12/13, Ubuntu 18/20/22/24.04, openSUSE Leap 15.6, Oracle Linux 8/9 y Amazon Linux 2023.

Por qué es importante: La vulnerabilidad aprovecha un programa auxiliar con privilegios instalado por defecto, solo requiere un shell local sin privilegios y cuenta con una prueba de concepto (PoC) pública que funciona. Cualquier host Linux en el que un atacante sin privilegios pueda ejecutar código debe considerarse en riesgo inmediato si están presentes cifs-utils y la regla predeterminada cifs.spnego, el módulo del núcleo CIFS está disponible, los espacios de nombres sin privilegios están habilitados y la política LSM no bloquea el pivote.

Haz lo siguiente ahora mismo: si tu servidor no monta recursos compartidos SMB autenticados mediante Kerberos (la mayoría de los servidores no lo hacen), anula o elimina la regla predeterminada «cifs.spnego request-key». Si no necesitas contenedores sin privilegios de root ni el uso de «unprivileged unshare», desactiva en su lugar los espacios de nombres de usuario sin privilegios. A continuación se indican los comandos y las ventajas e inconvenientes.

La versión larga

Asim Manizada dio a conocer CIFSwitch en la lista de correo oss-security el 28 de mayo de 2026, el día en que expiró el embargo acordado con linux-distros. El informe original se envió a los mantenedores del núcleo el 16 de mayo. La corrección del código fuente lleva más de una semana disponible públicamente y está en cola para la versión estable. Las distribuciones derivadas aún la están incorporando.

El problema del núcleo se remonta a la confirmación f1d662a de 2007, en la que se añadió el tipo de clave «cifs.spnego» sin un gancho de validación de la descripción. La vulnerabilidad permaneció latente durante 19 años porque la cadena de explotación práctica depende de dos adiciones posteriores: los espacios de nombres de usuario sin privilegios en Linux v3.8 (2013) y la lógica de cambio de espacio de nombres en cifs-utils (nominalmente, esto es a partir de la versión 6.14, pero las adaptaciones de otras correcciones de CVE también han introducido problemas en versiones anteriores de cifs-utils). Sin las tres piezas en el mismo lugar, la cadena no se ejecuta de principio a fin.

Manizada explica con franqueza en su artículo que el fallo se detectó mediante un razonamiento gráfico asistido por modelos de lenguaje grande (LLM) sobre objetos del núcleo, propiedades de seguridad y los límites en los que dichos objetos pasan del espacio del núcleo al espacio de usuario. La técnica de detección resulta interesante en sí misma. Por ahora, la pregunta más urgente es qué hace el fallo y cómo detenerlo.

Cómo funciona la vulnerabilidad

La vulnerabilidad se basa en una cadena de cuatro elementos: una función del núcleo de Linux denominada «keyrings», una herramienta del espacio de usuario llamada «cifs.upcall», los espacios de nombres de usuario de Linux y el Name Service Switch (NSS). Cada uno de estos elementos forma parte de la infraestructura habitual y cumple su función. El fallo radica en que nunca se aplicó un límite de confianza entre el núcleo y el espacio de usuario, y el resto de la cadena se deriva de ahí.

Paso 1: los llaveros del núcleo y el tipo de clave cifs.spnego

Los llaveros de Linux son un subsistema del núcleo que almacena material de autenticación, como tickets de Kerberos y claves de cifrado. Cuando el núcleo necesita una clave que no tiene, solicita al espacio de usuario que genere una mediante un mecanismo de llamada. Una regla en /etc/request-key.d/ indica: «Para generar una clave de este tipo, ejecute este programa auxiliar como root». Para montajes SMB o CIFS que utilizan Kerberos, el tipo de clave es cifs.spnego y el programa auxiliar predeterminado es /usr/sbin/cifs.upcall, incluido en el paquete cifs-utils.

Cuando el núcleo solicita una clave cifs.spnego, genera una cadena descriptiva que contiene campos de autoridad: el ID de usuario del montaje, el UID de las credenciales, el ID del proceso y el espacio de nombres de destino. Se supone que esa cadena procede del núcleo. El programa auxiliar del espacio de usuario confía en esos campos y los utiliza para decidir qué credenciales debe buscar y en qué espacio de nombres debe actuar.

Paso 2: comprobación de si falta el núcleo

El espacio de usuario puede llamar directamente a la llamada al sistema request_key() y solicitar una clave cifs.spnego con cualquier descripción que desee. Antes del parche, a la definición cifs_spnego_key_type del núcleo le faltaba el gancho .vet_description, que indica al subsistema de llaveros que «solo acepte descripciones procedentes de un origen específico». Sin ese gancho, cualquier proceso sin privilegios puede solicitar una clave cifs.spnego con una descripción falsificada, y el llavero ejecuta cifs.upcall como root con la descripción del atacante en mano.

Un detalle que conviene destacar desde el principio, según el análisis de Manizada: el núcleo no necesita devolver realmente una clave para que se ejecute «cifs.upcall». El programa auxiliar se ejecuta primero. Para cuando el núcleo rechaza la clave por ser inválida, el programa auxiliar de root ya ha hecho lo que el atacante quería. Eso es lo que hace que la falta del gancho de validación mencionado anteriormente tenga tantas consecuencias.

Paso 3: cambio de espacio de nombres dentro del ayudante raíz

cifs.upcall parses the description, finds upcall_target=app and pid=<some-pid>, and calls setns() to switch into the namespaces of the supplied pid. This is a deliberate feature, intended to make cifs.upcall resolve names against the right filesystem and network view when serving containerized mounts. The problem is that the kernel has just been tricked into trusting an attacker’s pid as if it came from a real kernel-side CIFS operation.

Paso 4: NSS como primitiva de carga de código

Antes de obtener privilegios de root, cifs.upcall realiza una búsqueda de cuentas mediante getpwuid(). En Linux, las búsquedas de cuentas se realizan a través del Name Service Switch (NSS), un sistema modular configurado en /etc/nsswitch.conf que determina qué bibliotecas compartidas se deben cargar para cada tipo de búsqueda. Ahora que cifs.upcall se encuentra dentro del espacio de nombres de montaje del atacante, el archivo nsswitch.conf que lee es el del atacante, y el módulo NSS que carga es un libnss_*.so.2 controlado por el atacante. Ese objeto compartido se ejecuta como root dentro del helper.

Paso 5: persistencia mediante sudo

El módulo NSS de la prueba de concepto pública crea un archivo en /etc/sudoers.d/ que concede al atacante el permiso NOPASSWD: ALL. Una vez que el proceso auxiliar se cierra, el atacante abandona el espacio de nombres y ejecuta sudo. El shell es de root. El binario de cifs.upcall almacenado en el disco no se ve afectado; el abuso se produce en el proceso auxiliar en ejecución y en el espacio de nombres controlado por el atacante.

La corrección es sencilla. El parche de origen añade una función de cuatro líneas, `cifs_spnego_key_vet_description()`, que compara `current_cred()` con el `spnego_cred` privado del núcleo. Si no coinciden, la solicitud de clave se rechaza con el error -EPERM. Solo la ruta de código CIFS del propio núcleo tiene permiso para instanciar una clave de este tipo. Eso basta para detener la cadena en el paso 2.

¿A quién afecta?

La ruta de código vulnerable de cifs.spnego se remonta a 2007, pero la cadena de explotación pública solo es accesible, en la práctica, en sistemas con soporte para espacios de nombres de usuario sin privilegios de la época de Linux v3.8 y que cumplan los demás requisitos previos. Que la cadena de explotación funcione en un host determinado depende de tres condiciones posteriores: si cifs-utils está instalado, si los espacios de nombres de usuario sin privilegios están habilitados y si la política LSM del host (SELinux o AppArmor) bloquea algún paso de la cadena.

Listo para su uso de serie (cifs-utils preinstalado, espacios de nombres sin privilegios activados, la política LSM predeterminada permite la cadena): AlmaLinux 9.7 Workstation y la imagen en la nube de Azure, Rocky Linux 9 Workstation, CentOS Stream 9 GNOME, Linux Mint Cinnamon 21.3 y 22.3, Kali Linux 2021.4 a 2026.1 sin interfaz gráfica, SLES 15 SP7, SLES SAP 15 SP7 y SLES SAP 16.

KernelCare también lo ha confirmado internamente en CloudLinux 10. CL se suministra con SELinux desactivado a través de sus perfiles «tuned», por lo que la excepción de SELinux que protege a RHEL 10, AlmaLinux 10, Rocky Linux 10 y Oracle Linux 10 no se aplica a CloudLinux 10.

Vulnerable si se instala «cifs-utils» manualmente: Ubuntu 18.04, 20.04, 22.04 y 24.04 (versiones de escritorio y servidor); la versión 24.04 requiere además el truco «aa-exec -p trinity», documentado públicamente, para eludir la política de usuarios de AppArmor; Pop!_OS 22.04 y 24.04; Debian 11, 12 y 13; CentOS Stream 9 Cinnamon/KDE/MATE/XFCE; Rocky Linux 9 KDE y Workstation-Lite; openSUSE Leap 15.6; Rocky Linux 8 GenericCloud; Oracle Linux 8 y 9 KVM; Amazon Linux 2023 KVM.

Bloqueado por la política predeterminada, pero vulnerable en el fondo: la mayoría de las distribuciones EL10 (RHEL 10, AlmaLinux 10, Rocky Linux 10, Oracle Linux 10) bloquean el pivote del espacio de nombres «cifs.upcall» cuando SELinux está en modo «enforcing». Ubuntu 26.04 bloquea la cadena bajo su política predeterminada de AppArmor userns. Fedora 40 a 44 y CentOS Stream 10 también lo bloquean de forma predeterminada. Estos hosts se vuelven vulnerables si el operador ejecuta setenforce 0 o relaja los sysctls de AppArmor userns.

No explotable por el público (PoC): Amazon Linux 2, que incluye cifs-utils 6.2 y es anterior a la lógica de cambio de espacios de nombres. CentOS 7 y RHEL 7, que tienen user.max_user_namespaces = 0 de forma predeterminada. Kali Linux 2019.4 y 2020.4 con la versión anterior de cifs-utils 6.9.

En última instancia, la vulnerabilidad depende de tres factores: si cifs.upcall está disponible, si se permite el uso de usuarios sin privilegios y si la política LSM bloquea el cambio de espacio de nombres. Comprueba estos aspectos con los comandos que se indican en la siguiente sección.

Actúa ya

La cadena tiene dos requisitos previos, y cada uno de ellos ofrece una mitigación clara. Elige el que mejor se adapte a tu carga de trabajo.

Recomendación: anular la regla predeterminada de clave de solicitud de cifs.spnego

Si el servidor no monta recursos compartidos SMB autenticados mediante Kerberos (la mayoría de los servidores no lo hacen), la regla predeterminada de clave de solicitud cifs.spnego no se utiliza. Si se anula, la cadena se detiene en el paso 1. Los montajes de clientes SMB basados en NTLM o contraseña no suelen depender de la llamada ascendente SPNEGO de Kerberos, pero comprueba tus opciones de montaje antes de eliminar la regla.

echo 'create cifs.spnego * * /usr/sbin/keyctl negate %k 30 %S' | sudo tee /etc/request-key.d/cifs.spnego.conf

Modifica la ruta de keyctl si tu distribución la tiene en otra ubicación. Esto se ajusta a la configuración alternativa recomendada por el autor y rechaza la solicitud de clave de forma clara, en lugar de provocar un error mediante un binario que no pertenece al llavero.

Si no utilizas SMB en absoluto, elimina el archivo por completo:

sudo rm /etc/request-key.d/cifs.spnego.conf

No apliques esto en los hosts que montan recursos compartidos SMB autenticados mediante Kerberos. cifs.upcall es precisamente el asistente de tickets SPNEGO del que dependen esos montajes.

Una vez aplicado el parche, revierte los cambios reinstalando cifs-utils (lo que restablecerá la regla predeterminada) o eliminando tu archivo de configuración personalizada.

Alternativa: desactivar los espacios de nombres de los usuarios sin privilegios

La prueba de concepto debe introducir un usuario privado y un espacio de nombres de montaje antes de activar la llamada ascendente. El bloqueo de usuarios sin privilegios interrumpe la cadena, independientemente del estado de cifs-utils.

# EL family:
sudo sysctl -w user.max_user_namespaces=0
echo 'user.max_user_namespaces = 0' | sudo tee /etc/sysctl.d/99-cifswitch.conf

# Debian / Ubuntu:
sudo sysctl -w kernel.unprivileged_userns_clone=0
echo 'kernel.unprivileged_userns_clone = 0' | sudo tee /etc/sysctl.d/99-cifswitch.conf

Nota sobre compatibilidad: los entornos de ejecución de contenedores sin privilegios (Podman sin privilegios, Docker sin privilegios, Flatpaks basados en bwrap), varios entornos de prueba de integración continua (CI), el comando unshare(1) sin privilegios y el entorno de prueba de Chromium requieren espacios de nombres de usuario sin privilegios. Es aceptable en entornos de alojamiento de cargas de trabajo, pero puede causar problemas en hosts de desarrollo o de contenedores.

Otra opción: desinstalar cifs-utils si no se utiliza el cliente SMB

La mayoría de los parques de servidores no lo necesitan. Al desinstalar el paquete, se eliminan tanto cifs.upcall como la regla predeterminada de request-key.

# Debian / Ubuntu
sudo apt remove cifs-utils

# RHEL / AlmaLinux / Rocky / Oracle / CentOS Stream
sudo dnf remove cifs-utils

Comprueba si tu servidor está expuesto

# Is cifs-utils installed?
command -v cifs.upcall && (rpm -q cifs-utils 2>/dev/null || dpkg -l cifs-utils 2>/dev/null)

# Is the default cifs.spnego request-key rule present?
cat /etc/request-key.d/cifs.spnego.conf 2>/dev/null

# Are unprivileged user namespaces enabled?
sysctl user.max_user_namespaces kernel.unprivileged_userns_clone 2>/dev/null

Un host solo es un objetivo válido si tiene instalado cifs.upcall, existe una regla de clave de solicitud cifs.spnego y se permite el acceso a usuarios sin privilegios.

Parche sin reinicio de KernelCare

Situación a las 14:00 UTC del 29 de mayo de 2026: Los parches sin reinicio para EL8 se han implementado en el canal principal. Los parches para AlmaLinux 9 también se han implementado en el canal principal. Los parches sin reinicio para el resto de variantes de EL9, EL10, los núcleos UEK de Oracle Linux (UEK6 y UEK7), Ubuntu, Debian y Proxmox VE se han implementado en el canal de pruebas.

Cuando esté disponible en el feed de prueba, sigue las instrucciones que se indican a continuación para solicitarlo:

kcarectl --update --prefix test

Una vez validado, el parche se instalará en la próxima ejecución programada, o bien puedes descargarlo cuando lo necesites:

kcarectl --update

Comprueba que el parche se haya aplicado. El parche se distribuye sin un identificador CVE y se puede identificar por la descripción del desarrollador original:

kcarectl --patch-info | grep 'cifs.spnego'
# expected: kpatch-description: smb: client: reject userspace cifs.spnego descriptions (cifs LPE)

Una vez asignado un CVE, la orden «kcarectl –patch-info | grep CVE-2026-» lo mostrará.

A qué hay que estar atento a medida que se desarrolla la situación

La asignación del CVE sigue pendiente. Las actualizaciones del núcleo de distribución de Red Hat, Ubuntu, Debian, SUSE, Oracle y Amazon se están implementando a medida que los proyectos derivados incorporan la adaptación estable en cola.

Iremos actualizando esta publicación a medida que se publiquen los parches que no requieren reinicio y se asigne el CVE.

Aplica parches a todos los kernels sin necesidad de reiniciar

Si aún no eres usuario de KernelCare, este es un buen momento para descubrir cómo los parches sin reinicio pueden proteger los sistemas Linux críticos sin necesidad de ventanas de mantenimiento de emergencia ni tiempos de inactividad.

Más información sobre KernelCare aquí →

Resumen

Nombre del artículo

Una vulnerabilidad en el núcleo de Linux de CIFSwitch permite obtener privilegios de root locales

Descripción

CIFSwitch es una vulnerabilidad de escalada de privilegios locales en Linux que puede otorgar privilegios de root en sistemas que utilicen cifs-utils, espacios de nombres de usuario y un manejo vulnerable de CIFS SPNEGO.

Autor

Chris DeMars

Nombre del editor

TuxCare

Logotipo de la editorial