Kernel Security on KnightLi Blog

CVE-2026-43494 / PinTheft: riesgo de elevacion local por la combinacion de Linux RDS e io_uring

Fri, 22 May 2026 15:16:59 +0800

CVE-2026-43494 es un riesgo de elevacion local de privilegios en el kernel Linux. La cadena de explotacion relacionada tambien se conoce publicamente como PinTheft. La clave no es una entrada remota, sino si un usuario local con pocos privilegios puede reunir al mismo tiempo RDS zerocopy, io_uring fixed buffers, un programa SUID-root legible y una version de kernel adecuada.

Conviene aclarar primero un detalle de nomenclatura: el directorio del repositorio Unclecheng-li/poc-lab se llama CVE-2026-43494 PinTheft, mientras que el titulo del README tambien menciona QVD-2026-27616 - PinTheft. Segun las entradas CVE publicas y avisos de terceros, CVE-2026-43494 apunta a un problema de Linux kernel RDS zerocopy en el que op_nents no se reinicia correctamente, lo que provoca una anomalia de double-free / conteo de referencias. QVD-2026-27616 parece mas bien un identificador de aviso de riesgo de Qianxin. En una investigacion real, registre ambos identificadores, pero tome como referencia principal los avisos de seguridad de la distribucion y el estado de los parches del kernel.

Cual Es el Nucleo de la Vulnerabilidad

El problema aparece en la ruta de envio zerocopy de Linux RDS, Reliable Datagram Sockets. Las descripciones publicas senalan estas funciones clave:

1
2

rds_message_zcopy_from_user()
rds_message_purge()

Cuando iov_iter_get_pages2() falla dentro de rds_message_zcopy_from_user(), las paginas que ya fueron fijadas pueden liberarse por la ruta de error, pero el estado relacionado con op_nents no se limpia correctamente. Mas tarde, rds_message_purge() todavia puede liberar otra vez las entradas residuales. El resultado es que las referencias de un mismo grupo de paginas se decrementan demasiadas veces, creando un error de conteo de referencias explotable.

Visto por separado, el bug de RDS es un problema de gestion de memoria en una ruta de error del kernel. PinTheft es peligroso porque la cadena de explotacion lo conecta con el mecanismo de buffers fijos de io_uring: io_uring conserva un struct page * antiguo, mientras que la pagina ya fue liberada y reasignada para otro uso. El PoC publico lleva ese estado hacia la sobrescritura del page cache de un programa SUID-root y finalmente alcanza elevacion local de privilegios.

Por Que Se Llama PinTheft

io_uring REGISTER_BUFFERS fija paginas de usuario. Para paginas normales, FOLL_PIN no es solo un incremento simple de una referencia; aumenta el page refcount mediante un bias mayor. El PoC publico usa el concepto GUP_PIN_COUNTING_BIAS = 1024.

El nombre PinTheft significa que la cadena de ataque “roba” repetidamente esas referencias pin a traves de la ruta de fallo de RDS zerocopy. Cuando las referencias se agotan, io_uring sigue creyendo que mantiene una pagina valida, pero esa pagina fisica ya puede liberarse y reutilizarse por el page cache.

Este tipo de vulnerabilidad se malinterpreta facilmente como “modificar directamente /usr/bin/su en disco”. Una descripcion mas precisa es que la cadena intenta sobrescribir el page cache en memoria. El archivo en si no necesariamente se escribe de vuelta al disco, pero cuando el kernel ejecuta ese programa SUID, puede leer instrucciones desde la cache de pagina contaminada y ejecutar la carga del atacante.

Las Condiciones de Activacion No Son Amplias

No es una vulnerabilidad del tipo “cualquier servidor Linux puede ser atacado remotamente”. La informacion publica indica que la cadena de explotacion depende al menos de estas condiciones:

El kernel tiene habilitados CONFIG_RDS y CONFIG_RDS_TCP.
El sistema tiene habilitado CONFIG_IO_URING, y kernel.io_uring_disabled=0.
Los modulos rds / rds_tcp ya estan cargados, o un usuario de bajos privilegios puede activar la carga automatica.
Existe localmente un binario SUID-root legible, como /usr/bin/su, /usr/bin/passwd o /usr/bin/pkexec.
El PoC publico tambien depende de la API mas reciente IORING_REGISTER_CLONE_BUFFERS. El analisis de CloudLinux indica que el PoC publico encaja mejor con kernel 6.13 o posterior.

Si falta cualquiera de estos enlaces, la ruta publica de explotacion se rompe. Por ejemplo, muchas distribuciones de la familia RHEL no compilan RDS por defecto, kernels antiguos de Ubuntu pueden no tener la API de clone buffer de io_uring que necesita el PoC, y algunos entornos restringen la carga automatica de modulos RDS por usuarios sin privilegios.

Autocomprobacion en Un Minuto

Primero, revise la configuracion del kernel:

1
2

zgrep -E "CONFIG_(RDS|RDS_TCP|IO_URING)" /proc/config.gz 2>/dev/null \
  || grep -E "CONFIG_(RDS|RDS_TCP|IO_URING)" /boot/config-$(uname -r)

Luego revise si io_uring esta deshabilitado:

`1`	`cat /proc/sys/kernel/io_uring_disabled 2>/dev/null`

Los valores comunes pueden interpretarse asi:

0: permitido, con la mayor superficie de riesgo.
1: restringido para usuarios sin privilegios; el comportamiento exacto depende de la version del kernel y la politica de la distribucion.
2: io_uring deshabilitado.

Revise si los modulos RDS existen y pueden cargarse:

1
2

lsmod | grep -E "^rds|^rds_tcp"
modprobe -n -v rds_tcp 2>&1 | head -3

Si CONFIG_RDS esta en not set, o el sistema no tiene ningun modulo rds_tcp, normalmente no se puede llegar a este bug. En cambio, si RDS esta disponible, io_uring no esta deshabilitado y el sistema usa un kernel general relativamente nuevo, conviene elevar la prioridad y seguir comprobando el estado de correccion de la distribucion.

Que Maquinas Merecen Prioridad

Priorice estos entornos:

Hosts Linux multiusuario, maquinas de ensenanza, bastiones y maquinas de desarrollo compartidas.
Hosts de contenedores, especialmente entornos que permiten usuarios locales no confiables o tienen una superficie de escape de contenedores mas laxa.
Escritorios o servidores con kernels mainline / rolling recientes, por ejemplo distribuciones rolling tipo Arch.
HPC, Oracle RAC u otros escenarios que puedan usar RDS de forma real.
CI workers, maquinas de compilacion y entornos de laboratorio que permiten a usuarios sin privilegios ejecutar mucho codigo local.

En un servidor web comun donde solo cuentas de servicio controladas ejecutan aplicaciones y RDS no esta habilitado, el riesgo practico baja mucho. Pero “mucho mas bajo” no significa “ignorar”: el impacto tipico de una elevacion local en kernel es que el atacante primero obtiene bajos privilegios mediante Web, SSH, CI, contenedores o una vulnerabilidad de aplicacion, y luego usa el bug local para ampliar su control.

Medidas Temporales de Mitigacion

La solucion formal debe seguir viniendo de la actualizacion del kernel de la distribucion. El estado de parches, versiones con backport y rangos afectados debe revisarse en los avisos de Debian, Ubuntu, RHEL, AlmaLinux, Rocky Linux, SUSE, Arch, proveedores cloud o imagenes base de contenedores. No juzgue solo por el numero de version upstream.

Mientras espera parches, o si no puede reiniciar el kernel de inmediato, puede elegir medidas temporales segun el entorno:

# Si el negocio no depende de RDS, bloquee la carga de los modulos relacionados
sudo sh -c "printf 'install rds /bin/false\ninstall rds_tcp /bin/false\ninstall rds_rdma /bin/false\n' > /etc/modprobe.d/pintheft.conf"
sudo rmmod rds_tcp 2>/dev/null
sudo rmmod rds_rdma 2>/dev/null
sudo rmmod rds 2>/dev/null

Si el negocio no depende de io_uring, tambien puede considerar deshabilitarlo o restringirlo:

`1`	`sudo sysctl -w kernel.io_uring_disabled=2`

La configuracion persistente debe escribirse en el archivo correspondiente bajo /etc/sysctl.d/*.conf. Tenga cuidado con este paso: bases de datos modernas, proxies, runtimes o programas de I/O de alto rendimiento pueden usar io_uring. Antes de cambiar produccion, confirme las dependencias del negocio.

Como Verificar Despues de Corregir

Tras actualizar el kernel, no se limite a mirar que el gestor de paquetes haya terminado con exito. Conviene confirmar tres cosas:

1
2
3

uname -a
cat /proc/sys/kernel/io_uring_disabled 2>/dev/null
modprobe -n -v rds_tcp 2>&1 | head -3

Si el aviso de la distribucion dice claramente que CVE-2026-43494 esta corregido, el kernel puede estar protegido aunque uname -r no parezca la version upstream mas reciente, porque el kernel estable de la distribucion puede haber recibido un parche con backport. En cambio, si el kernel proviene de una compilacion propia, un repositorio de terceros, una imagen de marketplace cloud o una plantilla de host de contenedores, siga verificando el commit del parche y la fecha de build.

Referencias

Impacto de cuatro problemas locales recientes en Linux: Copy Fail, Dirty Frag, Fragnesia y ssh-keysign-pwn

Wed, 20 May 2026 23:00:37 +0800

En las últimas semanas aparecieron varios problemas locales de seguridad de alto perfil en el ecosistema Linux. Por separado, afectan zonas distintas: interfaces criptográficas, rutas de red e IPsec, manejo de page cache y comprobaciones de acceso ptrace. En conjunto, apuntan a la misma lección operativa: si un atacante ya tiene un punto de ejecución local con pocos privilegios, el riesgo para hosts Linux, nodos de contenedores, máquinas de CI y servidores multiusuario aumenta de forma clara.

Este artículo no repite todos los detalles técnicos de cada vulnerabilidad. Resume su impacto práctico y enlaza cuatro análisis separados dentro del sitio.

Qué afecta cada uno de los cuatro eventos

Los cuatro riesgos que conviene seguir son:

Copy Fail (CVE-2026-31431): un usuario local con pocos privilegios puede afectar la page cache mediante rutas relacionadas con criptografía del kernel y ampliar privilegios.
Dirty Frag (relacionado con CVE-2026-43284 / CVE-2026-43500): el riesgo se concentra en xfrm/ESP, RxRPC y rutas de datos de red y kernel, con alto impacto en fases posteriores a una intrusión.
Fragnesia (CVE-2026-46300): cercano a Dirty Frag, gira alrededor de XFRM ESP-in-TCP, fragmentos compartidos y riesgo de escritura en page cache.
ssh-keysign-pwn (CVE-2026-46333): no es un bug de root shell directo, sino un riesgo local de divulgación de información que puede exponer claves privadas SSH del host, /etc/shadow y otros archivos sensibles.

Los puntos de entrada son distintos y las mitigaciones también. Arreglar Copy Fail no cubre automáticamente Dirty Frag o Fragnesia. Desactivar algunos módulos de red tampoco elimina por sí solo el riesgo de divulgación de información de ssh-keysign-pwn.

Copy Fail: alta prioridad para contenedores y nodos CI

El impacto clave de Copy Fail no es que una aplicación se bloquee. Es que una capacidad de ejecución con pocos privilegios puede convertirse en permisos de root. Es especialmente sensible en estos entornos:

Nodos CI/CD que permiten subir o ejecutar código.
Hosts de contenedores que ejecutan cargas no confiables.
Máquinas de desarrollo y prueba, jump hosts y servidores compartidos.
Hosts cloud con kernels antiguos y ciclos de parcheo lentos.

El peligro de Copy Fail está en su umbral de explotación relativamente bajo y en que se combina fácilmente con escenarios de contenedores. Muchos equipos tratan los contenedores como una frontera fuerte de aislamiento, pero los contenedores ordinarios siguen compartiendo el kernel del host por defecto. Si un atacante obtiene una shell dentro de un contenedor, una LPE del kernel puede convertir un problema del contenedor en un problema del host.

Análisis detallado: Copy Fail CVE-2026-31431: riesgo de escape de contenedor en una ruta de copia de archivos del kernel Linux.

Dirty Frag: un amplificador posterior a la intrusión

Dirty Frag se parece más a una herramienta de ampliación de privilegios después de que el atacante ya entró al sistema. No es una vulnerabilidad remota sin autenticación típica. El requisito habitual es que el atacante ya tenga ejecución local mediante una contraseña débil, WebShell, cuenta de servicio con pocos privilegios, tarea de contenedor u otro punto de apoyo.

Su impacto práctico aparece en varios lugares:

Una cuenta comprometida con pocos privilegios puede convertirse en root.
Un punto de ejecución con pocos privilegios dentro de un contenedor puede amenazar al host.
Los sistemas que usan IPsec, ESP, RxRPC o capacidades de red relacionadas del kernel necesitan revisar con cuidado parches y mitigaciones temporales.
Los equipos de seguridad no deben mirar solo la defensa perimetral, sino también las cadenas de escalada posteriores a la intrusión.

Dirty Frag recuerda a los equipos de operaciones que una LPE local quizá no sea la primera entrada, pero puede decidir hasta dónde llega una intrusión. Si existe un punto de apoyo con pocos privilegios, el atacante buscará bugs del kernel para llegar al nivel más alto.

Análisis detallado: Dirty Frag CVE-2026-43284: guía de riesgo y mitigación de escalada local en Linux.

Fragnesia: una superficie similar no se limpia de una sola vez

Fragnesia importa porque muestra que la superficie alrededor de Dirty Frag no es un problema aislado. Incluso si un bug se corrige, rutas vecinas, estructuras de datos similares y combinaciones de módulos relacionados pueden conservar nuevos puntos explotables.

Su impacto operativo principal es:

No tratar solo el nombre de la vulnerabilidad una vez. Hay que seguir revisando por superficie de ataque.
esp4, esp6, rxrpc, XFRM y ESP-in-TCP deben evaluarse según dependencias reales del negocio.
Si el sistema no depende de esas capacidades de red, se puede considerar una desactivación temporal, pero primero debe probarse para no romper VPN, IPsec, túneles o redes internas.
Los riesgos de contaminación de page cache pueden crear puntos ciegos: el archivo parece no cambiar, pero la ruta de ejecución queda afectada.

Para empresas, la lección principal es que la gestión de parches no debe mirar solo un CVE aislado. Es más seguro inventariar por subsistemas y superficies de ataque, identificar qué máquinas exponen esas capacidades y qué servicios realmente necesitan esos módulos.

Análisis detallado: Fragnesia (CVE-2026-46300): impacto y mitigación de una escalada local en el kernel Linux.

ssh-keysign-pwn: no da root directo, pero sigue siendo peligroso

ssh-keysign-pwn es distinto de los tres anteriores. Se parece más a una divulgación local de información sensible que a una vulnerabilidad de root shell directo. Pero en ataques reales, la divulgación de información sensible puede convertirse rápidamente en un incidente mayor.

Sus impactos principales incluyen:

La filtración de SSH host private keys puede afectar la confianza en la identidad del host.
El acceso a archivos como /etc/shadow puede permitir cracking offline y toma de cuentas.
Servidores multiusuario, jump hosts, máquinas de build y máquinas de desarrollo compartidas tienen mayor riesgo.
Aunque el atacante no escale privilegios de inmediato, puede obtener material de credenciales útil para movimiento lateral.

Este tipo de problema se subestima fácilmente porque no luce tan dramático como una shell root directa. Sin embargo, en entornos empresariales, la exposición de claves y hashes de contraseñas suele implicar una limpieza más larga: rotar claves SSH del host, revisar relaciones de confianza, comprobar contraseñas de cuentas y auditar logs de acceso.

Análisis detallado: ssh-keysign-pwn (CVE-2026-46333): divulgación local en Linux, claves SSH del host y riesgo sobre /etc/shadow.

Impacto común: los contenedores no son una frontera fuerte por defecto

Juntos, estos cuatro eventos dejan claro un punto: el aislamiento ordinario de contenedores no es aislamiento de máquina virtual.

Docker, containerd y Kubernetes usan namespaces, cgroups, capabilities, seccomp, AppArmor y SELinux para reducir superficie de ataque, pero normalmente siguen compartiendo el kernel del host. Si la vulnerabilidad está en el kernel compartido, un punto de ejecución con pocos privilegios dentro de un contenedor puede convertirse en entrada de ataque.

Los entornos de alto riesgo deberían revisar:

Si se permite ejecutar código no confiable en hosts compartidos.
Si los contenedores corren como root por defecto.
Si se conceden capabilities innecesarias.
Si las políticas seccomp son demasiado amplias.
Si cargas multi-tenant deberían moverse a gVisor, Kata Containers, Firecracker microVM, máquinas virtuales dedicadas o nodos dedicados.

Las plataformas CI/CD merecen atención especial. Los jobs de build ejecutan de forma natural código externo, scripts de instalación de dependencias, scripts de prueba y binarios temporales. Si esos jobs comparten hosts con servicios de larga duración, una sola escalada local puede afectar infraestructura mucho mayor.

Impacto común: los parches deben llegar al kernel en ejecución

Un error común al parchear kernels Linux es asumir que un paquete instalado significa que la máquina está ejecutando el kernel corregido.

Como mínimo, operaciones debería verificar tres cosas:

`1`	`uname -a`

Confirmar el kernel actualmente en ejecución.

`1`	`dpkg -l \| grep linux-image`

O en distribuciones de la familia RHEL:

`1`	`rpm -qa \| grep kernel`

Confirmar los paquetes de kernel instalados.

Finalmente, confirmar que la máquina reinició con el kernel corregido. Para servicios críticos que no pueden reiniciarse de inmediato, evaluar livepatch, hot patching o aislamiento temporal, pero no tratar la mitigación temporal como arreglo final.

Impacto común: reducir superficie de ataque debe ser específico

Estas vulnerabilidades recuerdan que endurecer Linux no puede quedarse en “actualizar el sistema” y “activar firewall”.

Revisiones más concretas incluyen:

Si AF_ALG / algif_aead se usa en cargas del negocio.
Si XFRM, ESP, ESP-in-TCP e IPsec son necesarios para VPN, túneles o gateways de seguridad.
Si RxRPC es necesario.
Si user namespaces no privilegiados deben estar habilitados.
Si los contenedores pueden crear tipos de socket demasiado amplios.
Si las políticas de acceso ptrace son demasiado permisivas.

Si el negocio no necesita ciertas capacidades, se puede evaluar desactivar módulos, ajustar sysctl, endurecer seccomp y reducir capabilities. No copies comandos a producción a ciegas. Primero inventaría dependencias y luego despliega gradualmente.

Orden de respuesta recomendado

Primero, prioriza máquinas donde la ejecución local de código está expuesta:

Hosts de contenedores.
CI/CD runners.
Jump hosts.
Servidores multiusuario.
Hosts que ejecutan servicios expuestos.
Sistemas que ejecutan plugins, scripts o extensiones no confiables.

Segundo, confirma avisos de la distribución y el kernel realmente en ejecución. No dependas solo del número de versión upstream. Debian, Ubuntu, RHEL, AlmaLinux, Rocky Linux, SUSE, openEuler y otras distribuciones pueden aplicar backports de seguridad.

Tercero, endurece políticas de ejecución de contenedores. Prioriza usuarios no root, capabilities mínimas, no-new-privileges, sistemas de archivos de solo lectura y políticas explícitas de seccomp más AppArmor o SELinux.

Cuarto, revisa exposición de claves y credenciales. Especialmente en entornos afectados por ssh-keysign-pwn, evalúa si SSH host keys, /etc/shadow, credenciales de jump hosts y CI secrets necesitan rotación.

Quinto, mejora monitoreo. Observa root shells anómalas, PoCs locales sospechosas de LPE, cambios en archivos críticos, comportamiento ptrace anómalo, procesos de contenedor accediendo a rutas del host y conexiones de red inusuales desde nodos CI.

Conclusión

El punto de estos cuatro eventos no es “Linux es inseguro”. El punto es que la confianza por defecto ya no alcanza.

Linux sigue siendo transparente, reparable, configurable y endurecible. Pero en entornos donde contenedores, CI, multi-tenancy y ejecución de código impulsada por IA son cada vez más comunes, un punto de ejecución con pocos privilegios ya no puede tratarse como un problema menor. Si el kernel contiene bugs explotables de escalada local o divulgación de información sensible, una intrusión parcial puede convertirse en control del host, exposición de credenciales o movimiento lateral.

El enfoque más realista es tomar estos cuatro eventos como recordatorio: parchear rápido, confirmar kernels reiniciados, habilitar módulos solo cuando sean necesarios, endurecer contenedores, hacer posible la rotación de claves y reevaluar niveles de aislamiento en cargas multi-tenant.

Lecturas relacionadas en este sitio:

ssh-keysign-pwn (CVE-2026-46333): filtración local de información en Linux, claves host SSH y riesgo para /etc/shadow

Sun, 17 May 2026 09:29:03 +0800

ssh-keysign-pwn se refiere a un conjunto de rutas de explotación alrededor de un fallo lógico en __ptrace_may_access() del Linux kernel, asignado como CVE-2026-46333. No es una vulnerabilidad remota sin autenticación y no entrega directamente una shell de root, pero el riesgo sigue siendo alto: un usuario local con pocos privilegios podría leer archivos sensibles de root que no debería poder acceder, como claves privadas de host SSH o /etc/shadow.

Para equipos de operaciones, la prioridad no es reproducir un PoC. La prioridad es identificar máquinas afectadas, actualizar el kernel, reiniciar para entrar en el kernel corregido y rotar claves de host SSH o restablecer contraseñas cuando sea necesario.

Conclusión rápida

Esta vulnerabilidad merece una prioridad alta por cuatro motivos:

La puede activar un usuario local de bajo privilegio, sin root.
Ya existe PoC público, lo que reduce mucho la barrera de explotación.
Los objetivos potenciales no son archivos comunes, sino claves privadas de host SSH y /etc/shadow.
La corrección requiere parche de kernel y reinicio; instalar paquetes sin reiniciar no basta.

Si tus servidores tienen múltiples usuarios, shell local, hosting compartido, CI runners, hosts de contenedores, aulas, bastiones o cualquier usuario local que no sea completamente confiable, conviene tratarlo primero.

Qué es la vulnerabilidad

Qualys publicó detalles en oss-security el 15 de mayo de 2026. Antes había informado a security@kernel.org de un problema lógico en __ptrace_may_access() del Linux kernel, y la corrección upstream ya había sido integrada por Linus. Después apareció código de explotación público, por lo que Qualys compartió la información en oss-security.

El equipo CVE del Linux kernel asignó luego CVE-2026-46333. La página de NVD muestra kernel.org como fuente, y la descripción corresponde al commit del kernel ptrace: slightly saner 'get_dumpable()' logic.

En términos simples, el fallo está en la ruta de salida de procesos. Cuando algunos procesos privilegiados están terminando, la lógica del kernel relacionada con las comprobaciones de acceso de ptrace puede omitir una comprobación dumpable que debería aplicarse, porque la tarea objetivo ya no tiene mm. Un atacante puede competir en una ventana muy estrecha y obtener descriptores de archivo que el proceso privilegiado en salida todavía mantiene abiertos.

Por eso se lo llama ssh-keysign-pwn: una de las rutas públicas de explotación gira alrededor de ssh-keysign para leer SSH host private keys.

Por qué puede exponer claves host SSH y /etc/shadow

En esencia, es una filtración local de información. Abusa de una ventana durante la salida de un programa privilegiado en la que el descriptor de memoria ya se separó, pero los descriptores de archivo aún no se cerraron.

El aviso de AlmaLinux explica el riesgo con claridad: si un programa privilegiado abrió archivos sensibles antes de bajar privilegios, y el atacante logra capturar el descriptor de archivo correspondiente durante la ventana de salida, esos archivos sensibles podrían leerse.

Dos objetivos frecuentes en la discusión pública son:

ssh-keysign: puede involucrar claves privadas de host SSH como /etc/ssh/ssh_host_*_key.
chage: puede involucrar /etc/shadow.

Si se filtran claves privadas de host SSH, un atacante podría suplantar el host y debilitar la confianza en la identidad SSH del servidor. Si se filtra /etc/shadow, un atacante puede crackear hashes de contraseña offline y ampliar el compromiso después.

Por eso debe tratarse como un problema de alta prioridad aunque no sea una vulnerabilidad de “root shell directo”.

Cómo evaluar la exposición

Desde la perspectiva upstream, es una vulnerabilidad del Linux kernel. Los registros de NVD muestran que el problema entró en el dataset de NVD el 15 de mayo de 2026, y en ese momento todavía no tenía puntuación CVSS.

El estado por distribución debe verificarse en los avisos de cada proveedor:

AlmaLinux 8, 9 y 10 publicaron orientación y el 16 de mayo de 2026 actualizaron el aviso para indicar que los patched kernels ya estaban en repositorios de producción.
Debian Security Tracker lista estados vulnerable/fixed y versiones corregidas para bullseye, bookworm, trixie, sid y otras ramas.
Para otras distribuciones, revisa las páginas oficiales de seguridad o repositorios de Ubuntu, Red Hat, SUSE, Arch, Alpine, etc.

No evalúes la seguridad solo por la versión upstream del kernel. Las distribuciones hacen backport de correcciones, por lo que un mismo número de versión aparente puede representar estados de parche diferentes.

Qué máquinas priorizar

Orden recomendado de prioridad:

Servidores multiusuario y hosts compartidos.
Bastiones, máquinas de enseñanza, equipos de desarrollo y otros sistemas con cuentas shell normales.
CI runners, máquinas de build y nodos de plataformas de hosting.
Hosts de contenedores y virtualización, sobre todo donde conviven workloads no completamente confiables.
Máquinas con servicios públicos. La vulnerabilidad requiere acceso local, pero el riesgo se combina si un bug web, RCE, contraseña débil u otro camino da al atacante un punto de apoyo de bajo privilegio.

Los escritorios de un solo usuario tienen un riesgo relativamente menor, pero aun así deberían actualizarse con el sistema. La ejecución local de código con bajo privilegio no es rara en escritorios, a través de navegadores, herramientas de desarrollo, scripts y software de terceros.

Recomendaciones de corrección

La solución preferida es instalar el kernel corregido que entrega la distribución y reiniciar.

Los comandos cambian por distribución, pero el principio es el mismo:

Actualizar metadatos de paquetes.
Instalar el paquete kernel que contiene la corrección de CVE-2026-46333.
Reiniciar en el kernel nuevo.
Usar uname -r y el aviso de seguridad de la distribución para verificar que el kernel en ejecución está corregido.

El aviso de AlmaLinux indica que los kernels corregidos están disponibles en repositorios de producción y que los usuarios pueden ejecutar el dnf upgrade habitual y reiniciar. Debian tracker también lista fixed versions para varias ramas.

Importante: si solo instalas un paquete kernel nuevo pero no reinicias, el kernel antiguo vulnerable sigue ejecutándose.

Mitigación temporal: endurecer ptrace_scope

Si no puedes reiniciar de inmediato, endurece primero ptrace_scope de Yama.

Qualys confirmó en una respuesta posterior en oss-security que configurar /proc/sys/kernel/yama/ptrace_scope en 2 (admin-only attach) o 3 (no attach) bloquea las rutas públicas de explotación que conocen. También aclararon que, en teoría, podrían existir otros métodos de explotación, por lo que esto es una mitigación, no una corrección.

Configuración temporal:

`1`	`sudo sysctl -w kernel.yama.ptrace_scope=3`

Configuración persistente:

`1`	`echo 'kernel.yama.ptrace_scope = 3' \| sudo tee /etc/sysctl.d/99-ssh-keysign-pwn.conf`

ptrace_scope=3 desactiva ptrace attach y puede afectar flujos de depuración como gdb y strace -p. Si necesitas depuración en producción, evalúa 2. En cualquier caso, agenda la actualización de kernel y el reinicio cuanto antes.

¿Hay que rotar claves host SSH?

Conviene adoptar una postura conservadora si la máquina tenía alguna de estas condiciones durante la ventana de exposición:

Usuarios locales no confiables.
Hosting compartido o entornos multi-tenant de contenedores/CI.
Vulnerabilidades web, contraseñas débiles, scripts de cadena de suministro u otros caminos que puedan dar un punto de apoyo local.
Procesos locales sospechosos, comportamiento de depuración anómalo o archivos PoC públicos en logs.
Exposición prolongada antes de aplicar la corrección.

Una respuesta conservadora incluye:

Rotar SSH host keys después de parchear y reiniciar.
Actualizar sistemas de gestión de huellas de hosts conocidos.
Notificar a automatizaciones que dependan de esa huella de host.
Revisar alertas de conexión SSH para no confundir cambios legítimos de huella con ataques de intermediario, ni ignorar riesgos reales.

Si sospechas que /etc/shadow se filtró, evalúa también restablecimiento de contraseñas, prohibición de contraseñas débiles y revisión de hashes antiguos que puedan crackearse offline.

Qué monitorear

La ventana de explotación es breve, así que los logs tradicionales podrían no capturarlo todo. Aun así, revisa:

Archivos como ssh-keysign-pwn, chage_pwn o artefactos PoC similares en directorios de usuarios normales.
Actividad de compilación sospechosa, como programas C desconocidos compilados en poco tiempo.
Señales de acceso anómalo a /etc/ssh/ssh_host_*_key o /etc/shadow.
Actividad inusual de pidfd_getfd, ptrace o depuradores.
Reportes externos de cambios inesperados en la huella del host SSH.

Estas señales no prueban que hubo explotación, y su ausencia tampoco prueba que no la hubo. Las prioridades reales siguen siendo parchear, reiniciar, rotar credenciales y aislar el riesgo.

Malentendidos comunes

Primero: no es una vulnerabilidad remota de OpenSSH. El nombre incluye ssh-keysign, pero la causa raíz está en la lógica de comprobación de acceso ptrace del Linux kernel, no en el flujo de autenticación remota de sshd.

Segundo: no tener usuarios locales no elimina todo el riesgo. La vulnerabilidad sí requiere ejecución local, pero muchas cadenas reales obtienen primero un punto de apoyo local de bajo privilegio mediante servicios web, CI, scripts, contraseñas débiles o escapes de contenedor.

Tercero: configurar ptrace_scope no basta. Es una mitigación temporal, no una corrección raíz. La actualización del kernel y el reinicio siguen siendo necesarios.

Cuarto: no haber obtenido root no significa que no haya incidente. La filtración de claves privadas de host SSH o /etc/shadow puede bastar para movimiento lateral, suplantación de host y cracking offline.

Checklist de respuesta

Orden recomendado:

Inventariar hosts Linux afectados, especialmente entornos multiusuario y compartidos.
Revisar avisos oficiales de seguridad de la distribución e identificar la fixed kernel version.
Instalar el kernel corregido y reiniciar.
En máquinas que no puedan reiniciarse de inmediato, configurar kernel.yama.ptrace_scope=2 o 3.
Verificar la versión del kernel en ejecución después de la corrección.
Rotar SSH host keys en máquinas de alto riesgo.
Si se sospecha exposición de /etc/shadow, evaluar restablecimiento de contraseñas y auditoría de cuentas.
Buscar PoCs públicos, compilaciones anómalas y comportamiento local de depuración sospechoso.

Resumen

ssh-keysign-pwn (CVE-2026-46333) es una vulnerabilidad local de filtración de información causada por lógica relacionada con __ptrace_may_access() en el Linux kernel. No permite entrar remotamente de forma directa y no concede una shell de root directa, pero puede permitir que un usuario local de bajo privilegio lea archivos sensibles de alto valor. Eso la vuelve especialmente importante en entornos multiusuario, hosting compartido, CI y hosts de contenedores.

La corrección fiable es actualizar al kernel corregido de la distribución y reiniciar. ptrace_scope=2/3 puede servir como mitigación temporal, pero no reemplaza el parche. En hosts críticos expuestos durante la ventana de riesgo, también conviene evaluar rotación de claves host SSH y riesgo de contraseñas.

Referencias:

Dirty Frag CVE-2026-43284: riesgo de escalada local en Linux y guía de mitigación

Sat, 09 May 2026 07:25:55 +0800

Dirty Frag es un conjunto de vulnerabilidades de escalada local de privilegios en el kernel Linux, divulgadas en mayo de 2026 y con indicios de explotación activa. Microsoft la describe como un riesgo post-compromiso: después de que un atacante consigue ejecución con pocos privilegios, puede usar el fallo para escalar a root. Ubuntu también clasifica CVE-2026-43284 como High.

El peligro no está en un “compromiso remoto de un clic”. El peligro está en que, una vez dentro, el atacante puede ampliar el control rápidamente. Si consigue ejecución local mediante credenciales SSH débiles, una web shell, escape de contenedor, una cuenta de servicio con pocos privilegios o acceso remoto tras phishing, Dirty Frag puede permitir root y luego desactivar herramientas de seguridad, leer credenciales, manipular logs, moverse lateralmente o persistir.

Qué CVE están implicados

La información pública asocia Dirty Frag principalmente con dos identificadores:

CVE-2026-43284: relacionado con la ruta xfrm/ESP del kernel Linux. Las referencias de Microsoft a esp4 y esp6 pertenecen a esta zona de riesgo.
CVE-2026-43500: Microsoft indica que está relacionado con rxrpc, pero al 8 de mayo de 2026 el CVE aún no estaba publicado en NVD y el estado de parches seguía evolucionando.

Por eso no conviene mirar solo un CVE. Es más seguro revisar si esp4, esp6, rxrpc y funciones relacionadas con xfrm/IPsec están activas, son necesarias y ya tienen parche de la distribución.

Explicación técnica resumida

Según Microsoft y Ubuntu, CVE-2026-43284 afecta al manejo de red y fragmentos de memoria del kernel Linux, especialmente al tratamiento de fragmentos de página compartidos en la ruta ESP/IPsec.

En términos simples, páginas de datos pueden adjuntarse a buffers de red mediante mecanismos como splice. Si rutas posteriores del kernel tratan esos fragmentos como datos privados que se pueden modificar in-place, puede producirse descifrado o modificación in-place donde no debería. Un atacante puede manipular el comportamiento de page cache y acabar logrando escalada local.

Esto se parece a CopyFail (CVE-2026-31431): ambos giran en torno a page cache de Linux, rutas de datos del kernel y escalada local. Dirty Frag es peligroso porque introduce más rutas de ataque y puede ser más fiable que exploits LPE tradicionales dependientes de ventanas de carrera estrechas.

Entornos prioritarios

Dirty Frag es una vulnerabilidad local, así que el atacante ya debe poder ejecutar código en la máquina. Prioriza:

Servidores Linux con SSH expuesto.
Servidores web donde pueda escribirse una web shell.
Hosts multiusuario, bastiones, máquinas de desarrollo y runners CI/CD.
Hosts de contenedores, nodos Kubernetes y nodos OpenShift.
Sistemas que usen IPsec, VPN, xfrm o funcionalidad relacionada con RxRPC.
Servidores con Ubuntu, RHEL, CentOS Stream, AlmaLinux, Fedora, openSUSE y otras distribuciones comunes.

Si un servidor no tiene usuarios locales, contenedores ni rutas de aplicación expuestas, el riesgo es menor. Pero cualquier sistema donde un atacante pueda conseguir una shell de bajo privilegio debe tratar esto como un problema de kernel de alta prioridad.

Primero parchear

La corrección más segura es instalar la actualización de seguridad del kernel de tu distribución y reiniciar con el kernel nuevo.

La página de Ubuntu indica que CVE-2026-43284 se publicó el 8 de mayo de 2026 y se clasifica como High. Microsoft también dice que Linux Kernel Organization publicó correcciones para CVE-2026-43284 y recomienda aplicar parches cuanto antes.

Empieza revisando el sistema:

1
2

uname -a
cat /etc/os-release

Después actualiza el kernel según la distribución:

`1`	`sudo apt update && sudo apt full-upgrade`

`1`	`sudo dnf update`

Tras actualizar, confirma que el sistema arrancó con el kernel nuevo:

`1`	`uname -r`

Instalar paquetes de kernel sin reiniciar deja el kernel antiguo ejecutándose, así que la vulnerabilidad puede seguir presente.

Mitigación temporal: desactivar módulos relacionados

Si aún no hay parches, o producción no puede reiniciarse de inmediato, evalúa si puedes desactivar temporalmente los módulos relacionados. La mitigación de Ubuntu bloquea la carga de esp4, esp6 y rxrpc, y los descarga si ya están cargados.

Crear reglas modprobe:

1
2
3

echo "install esp4 /bin/false" | sudo tee /etc/modprobe.d/dirty-frag.conf
echo "install esp6 /bin/false" | sudo tee -a /etc/modprobe.d/dirty-frag.conf
echo "install rxrpc /bin/false" | sudo tee -a /etc/modprobe.d/dirty-frag.conf

Actualizar initramfs para evitar carga temprana:

`1`	`sudo update-initramfs -u -k all`

Descargar módulos ya cargados:

`1`	`sudo rmmod esp4 esp6 rxrpc 2>/dev/null`

Comprobar si siguen cargados:

`1`	`grep -qE '^(esp4\|esp6\|rxrpc) ' /proc/modules && echo "Affected modules are loaded" \|\| echo "Affected modules are NOT loaded"`

Si un módulo está en uso, puede no descargarse. En ese caso, la regla de bloqueo probablemente solo surtirá efecto tras reiniciar.

Evalúa impacto antes de desactivar

No pegues esos comandos a ciegas. esp4, esp6 y funciones xfrm/IPsec pueden usarse en VPN, túneles, redes cifradas, redes Kubernetes/contenedores o configuraciones empresariales. rxrpc también puede afectar cargas que dependan de ese protocolo.

Antes de ejecutar en producción, revisa al menos:

1
2
3

lsmod | grep -E '^(esp4|esp6|rxrpc|xfrm)'
ip xfrm state
ip xfrm policy

Si dependes de IPsec VPN o funciones relacionadas del kernel, desactivar módulos puede cortar conectividad. En ese caso, es mejor programar parcheo del kernel y ventana de mantenimiento que depender mucho tiempo del bloqueo de módulos.

No omitas comprobaciones post-compromiso

Microsoft recuerda que la mitigación no necesariamente revierte cambios ya introducidos por explotación exitosa. Si el atacante ya obtuvo root, puede haber dejado persistencia, modificado archivos, alterado logs o accedido a datos de sesión.

Comprueba al menos:

journalctl -k --since "24 hours ago" | grep -Ei "dirty|frag|exploit|segfault|xfrm|rxrpc|esp"
last -a
lastlog
sudo find /tmp /var/tmp /dev/shm -type f -mtime -3 -ls
sudo find / -perm -4000 -type f -mtime -7 -ls 2>/dev/null

También revisa:

Lanzamientos anómalos de su, sudo o procesos SUID/SGID.
Ejecutables ELF creados recientemente.
Archivos PHP, JSP o ASP sospechosos en directorios web.
Cambios en SSH authorized_keys.
Persistencia nueva en systemd services, cron o rc.local.
Contenedores privilegiados o montajes sospechosos en hosts de contenedores.

Si sospechas explotación, aísla el host, conserva evidencias, rota credenciales y luego limpia. No asumas que descargar módulos o limpiar cachés hace seguro el sistema.

Sobre drop_caches

Microsoft menciona que en algunos escenarios de verificación de integridad post-explotación puede evaluarse limpiar caché:

`1`	`echo 3 \| sudo tee /proc/sys/vm/drop_caches`

Esto no es una corrección de la vulnerabilidad ni un comando de limpieza de incidente. Limpiar cachés puede aumentar I/O de disco y afectar rendimiento en producción. Úsalo solo como paso auxiliar tras entender el impacto. La corrección real sigue siendo parchear, reiniciar, verificar integridad y revisar persistencia.

Orden recomendado de respuesta

Para producción, una secuencia razonable es:

Inventariar activos Linux y versiones de kernel.
Priorizar sistemas con SSH expuesto, workloads web, hosts de contenedores y acceso multiusuario.
Parchear y reiniciar cuanto antes los sistemas que puedan reiniciarse.
En sistemas que aún no puedan parchearse o reiniciarse, evaluar desactivar esp4, esp6 y rxrpc.
Aumentar monitorización de su, SUID/SGID, ELF sospechosos, web shells e indicadores de escape de contenedor.
Ejecutar comprobaciones post-compromiso y rotar credenciales en hosts sospechosos.

Resumen

Dirty Frag no es una vulnerabilidad “remote one-click”, pero aumenta mucho el riesgo tras una intrusión. Si un atacante puede ejecutar código local con pocos privilegios, CVE-2026-43284 y la superficie asociada a rxrpc pueden permitir escalada a root.

Para administradores, la prioridad no es estudiar PoC. La prioridad es confirmar exposición del kernel, instalar actualizaciones de seguridad de la distribución y reiniciar, evaluar mitigaciones de bloqueo de módulos antes de la ventana de parcheo, e inspeccionar sistemas expuestos o sospechosos en busca de problemas de integridad y persistencia.

Referencias: