Una semana después de «Copy Fail» (CVE-2026-31431), el investigador Hyunwoo Kim reveló una segunda vulnerabilidad de escalada de privilegios locales en el núcleo de Linux dentro del mismo ámbito general —IPsec ESP y rxrpc— y la denominó «Dirty Frag». Existe una prueba de concepto pública que funciona. Cualquier usuario local sin privilegios puede utilizarla para obtener privilegios de root con un solo comando.
El equipo técnico de KernelCare publicó parches en tiempo real para toda la familia de kernels EL8 en las 24 horas siguientes a la divulgación, antes de que los proveedores publicaran sus respectivas erratas, y EL9, Ubuntu, Debian y Proxmox VE siguieron la misma línea de lanzamiento. El parche se aplica al kernel en ejecución y surte efecto sin necesidad de reiniciar el sistema.
Existe un segundo exploit público denominado«Copy Fail 2: Electric Boogaloo»que hace referencia a esta misma vulnerabilidad bajo ese alias. No existe un CVE independiente para «Copy Fail 2». Todo lo indicado en este aviso es aplicable.
Antecedentes: demostración de concepto pública y informe técnico · Divulgación en oss-security · Entrada en la NVD para CVE-2026-43284 · Corrección en el proyecto original
Por qué es urgente
La vulnerabilidad se encuentra en la ruta de descifrado in situ de esp4, esp6 y rxrpc. Cuando la ruta de recepción descifra a través de búferes paginados que no son propiedad privada del núcleo (por ejemplo, páginas de tubería que llegan al socket mediante splice(2) / sendfile(2)), los procesos sin privilegios pueden conservar referencias al texto sin cifrar resultante, lo que da lugar a una primitiva de escritura en la caché de páginas que la prueba de concepto pública convierte en root con un solo comando.
El embargo de divulgación responsable se rompió el 7 de mayo de 2026 antes de que las distribuciones pudieran coordinarse. Un exploit operativo se hizo público antes de que se asignaran los identificadores CVE y de que estuvieran listas las correcciones del proveedor. En cualquier sistema en el que usuarios no de confianza puedan ejecutar código, esto debe tratarse como un caso de aplicación de parches el mismo día.
Actualización sobre la asignación de CVE:
- La vulnerabilidad de escritura en la caché de páginas de xfrm-ESP se registra con el número CVE-2026-43284.
- La vulnerabilidad de escritura en la caché de páginas de rxrpc se ha registrado con el número CVE-2026-43500 (entrada en la NVD pendiente).
Parches en tiempo real de KernelCare: ya disponibles, sin necesidad de reiniciar
KernelCare publicó parches en tiempo real antes de que los proveedores publicaran sus erratas en todas las distribuciones compatibles:
- Familia EL8 (RHEL 8, CentOS 8, Oracle Linux 8, CloudLinux 8, CloudLinux 7 Hybrid, AlmaLinux 8, Rocky Linux 8)
- Familia EL9 (RHEL 9, AlmaLinux 9, Oracle Linux 9, Rocky Linux 9)
- Ubuntu 22.04 LTS (Jammy), incluidas las variantes AWS y HWE
- Debian 12 (Bookworm)
- Proxmox VE 7 (núcleo 5.15) y Proxmox VE 8
Los clientes recibirán la corrección automáticamente la próxima vez que ejecuten el comando «kcarectl –update».
También se tratan los ELS para los núcleos FIPS
Los núcleos con soporte de ciclo de vida ilimitado (ELS) de TuxCare para AlmaLinux 9.2 y 9.6, validados según la norma FIPS, ya han sido parcheados. Los clientes de ELS-FIPS recibirán la corrección a través del mismo canal de distribución de KernelCare (versiones K20260508_20 y K20260508_19, respectivamente) sin necesidad de realizar ninguna acción adicional.
Lo que deben hacer los clientes de KernelCare
En la mayoría de los casos, nada. Si la actualización automática de kcarectl está activada (por defecto), el parche se descarga y se aplica en la siguiente consulta programada. Para aplicarlo de inmediato:
kcarectl --update
Cómo comprobar si tienes instaladas las actualizaciones
Comprueba la fecha de compilación del parche cargado:
kcarectl --info | grep kpatch-build-time
Cualquier parche con fecha del 8 de mayo de 2026 o posterior incluye la corrección. Para verificarlo por la referencia CVE:
kcarectl --patch-info | grep -i 'CVE-2026-43284\|CVE-2026-43500\|dirty.frag\|xfrm'
La cadena de versión del núcleo que devuelve el comando «uname -r» no cambia con KernelCare, ya que el núcleo en ejecución se modifica en memoria en lugar de sustituirse en el disco.
Solución provisional (si no puedes actualizar de inmediato)
Si no es posible aplicar el parche en vivo de KernelCare en este momento, añade a la lista negra los módulos esp4, esp6 y rxrpc para que no se puedan cargar, y descárgalos si ya están presentes:
sudo sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; true"
Para revertir los cambios tras aplicar el parche en vivo:
sudo rm /etc/modprobe.d/dirtyfrag.conf
Compatibilidad: esp4 y esp6 son las transformaciones ESP del núcleo utilizadas por IPsec. Desactivarlas interrumpe los túneles IPsec que dependen de la ruta de datos del núcleo en el equipo afectado. No apliques esta medida correctiva en equipos que terminen o por los que transiten túneles IPsec, strongSwan o Libreswan. rxrpc es el transporte AF_RXRPC utilizado casi exclusivamente por los clientes AFS y no está presente en los servidores típicos de alojamiento web.
Restaurar los archivos binarios de la caché de páginas tras la mitigación
La vulnerabilidad permite modificar archivos binarios legítimos del sistema en la caché de páginas como parte del proceso para obtener privilegios de root, por lo que la medida de mitigación por sí sola no es suficiente en sistemas que puedan haber sido objeto de ataques antes de que se aplicara dicha medida. Tras aplicar la mitigación, vacíe la caché de páginas:
echo 3 | sudo tee /proc/sys/vm/drop_caches
Enlaces
- PoC canónico (Hyunwoo Kim / V4bel)
- Resumen del investigador (dirtyfrag.io)
- Hilo sobre la divulgación de información de seguridad de OSS
- hilo de lore.kernel.org
- Entrada de la NVD para CVE-2026-43284
- Corrección en el código fuente (netdev/net.git, commit f4c50a4034e62ab75f1d5cdd191dd5f9c77fdff4)
¿Aún no utilizas KernelCare?
KernelCare ofrece parches en tiempo real para las vulnerabilidades CVE del núcleo en sistemas en funcionamiento, sin necesidad de reiniciar ni de interrumpir el servicio. El mismo modelo de implementación que permitió corregir la vulnerabilidad «Dirty Frag» en menos de 24 horas tras su divulgación pública se aplicará en adelante a todas las vulnerabilidades CVE de alta gravedad del núcleo.
