Script de Validación Defensiva CVE-2026-23111

Descripción general

CVE-2026-23111 es una vulnerabilidad del kernel de Linux en nf_tables que puede ser explotada para la escalada local de privilegios por un usuario sin privilegios en sistemas donde los espacios de nombres de usuario (user namespaces) y nftables están disponibles.[1][2] Los avisos públicos de proveedores y gobiernos la describen como un problema local que afecta a las distribuciones Linux y enfatizan la aplicación de parches como la solución principal.[3][4]

Este repositorio contiene un script de validación defensiva diseñado para ayudar a evaluar si un host expone las condiciones técnicas asociadas con esta CVE sin proporcionar un exploit de escalada de privilegios. Comprueba las condiciones relevantes del kernel y del entorno de ejecución, carga opcionalmente el módulo nf_tables para realizar pruebas funcionales completas, intenta una ruta de validación controlada sin privilegios usando unshare y nft, recopila trazas de diagnóstico locales y clasifica el host en veredictos operativos como probablemente seguro, bloqueado por política local, o ruta expuesta disponible.[1][5]

En qué consiste la CVE

Según el NVD, CVE-2026-23111 es una vulnerabilidad de nf_tables en el kernel de Linux resuelta como una corrección de un error lógico en netfilter y es explotable para la escalada local de privilegios desde un usuario sin privilegios a través de los espacios de nombres de usuario y nftables en configuraciones afectadas.[1] El aviso de seguridad de Ubuntu describe la misma ruta de explotación de alto nivel y realiza el seguimiento de los estados de los paquetes afectados y corregidos por versión.[2]

Red Hat afirma que un usuario local con privilegios bajos podría explotar el problema para causar una denegación de servicio o potencialmente lograr una escalada de privilegios, y documenta una ruta de mitigación basada en impedir que el módulo nf_tables se cargue cuando eso sea operativamente aceptable.[3] La guía a nivel nacional del Centro Canadiense de Ciberseguridad también remite a las organizaciones afectadas a las actualizaciones de los proveedores y menciona la regeneración del initramfs cuando se utilizan mitigaciones de bloqueo de módulos.[4]

Qué hace el script

El script está pensado para la evaluación defensiva de exposición, no para la explotación. Está diseñado para:

• Identificar el kernel en ejecución, la familia de distribución y los ajustes relevantes de endurecimiento del entorno de ejecución.
• Comprobar si CONFIG_USER_NS y CONFIG_NF_TABLES parecen estar presentes.[1]
• Inspeccionar kernel.unprivileged_userns_clone y user.max_user_namespaces para estimar si los espacios de nombres de usuario sin privilegios están disponibles.
• Detectar si existe una denegación estricta de modprobe (install nf_tables /bin/false) o una lista negra débil para el módulo nf_tables.
• Revisar el changelog del RPM del kernel del proveedor en busca de una entrada de backport de CVE-2026-23111 (solo familia RHEL).
• Obtener la huella de /proc/kallsyms para el símbolo vulnerable (nft_map_catchall_activate) frente al símbolo posterior al parche (nft_catchall_set_activate) antes de cualquier interacción con el módulo.
• Cargar opcionalmente nf_tables mediante modprobe cuando se especifica --allow-load-module (ver más abajo), y descargarlo automáticamente al salir.
• Ejecutar un paso de validación restringido con unshare -U -n --map-root-user + nft cuando el módulo está cargado, y registrar stdout, stderr y los registros recientes del kernel.
• Verificar que unshare --user realmente crea un espacio de nombres y que CAP_NET_ADMIN es funcional dentro de él, para confirmar si las restricciones de AppArmor o SELinux son realmente efectivas.
• Señalar si los controles de seguridad locales como AppArmor o SELinux parecen bloquear la ruta probada.[6]
• Emitir una salida orientada a veredictos con resaltado de color opcional para facilitar el triaje.

El script almacena los registros en un subdirectorio del directorio del script y los elimina de forma predeterminada a menos que se use --keep-logs.

Política de carga de módulos

De forma predeterminada, el script nunca carga nf_tables. Si el módulo no está ya cargado cuando el script se inicia, todas las pruebas funcionales de nft se omiten y el veredicto se deriva únicamente de la versión del kernel, la huella de kallsyms, la configuración de modprobe, el changelog del RPM y la evidencia de política sysctl/LSM.

Este valor predeterminado conservador evita ampliar involuntariamente la superficie de ataque en hosts de producción. Para habilitar las pruebas funcionales completas en un sistema controlado o instrumentado, use --allow-load-module como root (ver más abajo).

Uso

# Default — no module loading, policy-evidence-only verdict
./check_cve_2026_23111.sh
./check_cve_2026_23111.sh --color
./check_cve_2026_23111.sh --keep-logs
./check_cve_2026_23111.sh --color --keep-logs

# Full functional test — loads (and unloads) nf_tables, requires root
sudo ./check_cve_2026_23111.sh --allow-load-module
sudo ./check_cve_2026_23111.sh --allow-load-module --color --keep-logs

Opciones

Opción	Descripción
--allow-load-module	Autoriza al script a cargar nf_tables mediante modprobe si el módulo no está ya cargado. Habilita el ejercitador completo de la ruta catchall de nft y la prueba de efectividad de CAP_NET_ADMIN. El módulo se descarga automáticamente al salir. Requiere root. Se rechaza si ya existe una denegación estricta de modprobe. Úselo solo en sistemas que no sean de producción o instrumentados.
--color	Habilita la salida stdout coloreada cuando el terminal lo soporta.
--keep-logs	Mantiene los registros y las trazas en el directorio del script en lugar de eliminarlos al salir.
--help	Muestra la información de uso y sale.

Cuándo usar --allow-load-module

Use --allow-load-module cuando necesite el veredicto de mayor confianza en una VM de prueba aislada, que no sea de producción o creada específicamente para ello. Escenarios típicos:

• Se está validando un kernel dentro del rango vulnerable antes de implementar la corrección del proveedor.
• El sistema de prueba tiene KASAN u otra instrumentación habilitada y desea observar las trazas del kernel.
• El módulo no está en uso en el host de destino y se requiere una verificación completa de extremo a extremo de la ruta como evidencia de auditoría.

No use --allow-load-module en hosts de producción donde nf_tables esté bloqueado intencionalmente o donde cargarlo violaría una política de endurecimiento.

Controles de seguridad para --allow-load-module

Antes de intentar cargar el módulo, el script aplica las siguientes comprobaciones y sale con un error si alguna falla:

1. Una denegación estricta de modprobe (install nf_tables /bin/false) no debe estar presente en /etc/modprobe.d/.
2. modprobe debe estar disponible en el sistema.
3. El script debe ejecutarse como root (uid 0).

Si el script carga el módulo correctamente, se llama a modprobe -r nf_tables al salir mediante la trampa cleanup(), independientemente de cómo termine el script (con éxito, con error o con CTRL+C).

Modelo de veredictos

El script utiliza veredictos operativos en lugar de resultados de explotación: