Todas las notas

Dirty Frag: el sucesor de Copy Fail que llegó sin parches listos

CVE-2026-43284 y CVE-2026-43500 repiten la misma clase de ataque que Copy Fail pero vía IPsec y RxRPC. El PoC es público, un parche está pendiente, y la divulgación fue forzada. Acá explicamos qué hace y cómo protegerse.

Dirty Frag: el sucesor de Copy Fail que llegó sin parches listos

Hace diez días escribimos sobre Copy Fail: 732 bytes de Python, root garantizado en cualquier Linux desde 2017. Esta semana apareció su sucesor directo.

Se llama Dirty Frag. CVE-2026-43284 y CVE-2026-43500. Mismo tipo de ataque, distintos subsistemas, y una diferencia importante: fue divulgado antes de que los parches estuvieran listos.

Qué hace

Dirty Frag encadena dos fallos en el kernel Linux que permiten a cualquier usuario local sin privilegios escribir en el page cache de archivos protegidos y obtener root.

El mecanismo es el mismo que en Copy Fail: una escritura controlada en memoria compartida que el kernel no debería dejar tocar. Pero donde Copy Fail explotaba el módulo algif_aead de la interfaz criptográfica AF_ALG, Dirty Frag usa dos rutas distintas:

  • CVE-2026-43284 — el subsistema xfrm-ESP (IPsec, los módulos esp4 y esp6). El bug está ahí desde ~2017.
  • CVE-2026-43500 — el subsistema RxRPC (Remote Procedure Call de kernel, usado en AFS). Este existe desde ~2023.

El exploit aprovecha que durante operaciones de desencriptación, el kernel retiene referencias a páginas del page cache en buffers que deberían ser privados. Esa referencia es la rendija: el atacante la usa para escribir en la memoria de un binario setuid y ejecutar código como root.

El resultado es el mismo de siempre. Sin carreras de condición. Determinista. Público.

La relación con Copy Fail

Dirty Frag no es una coincidencia. Lo descubrió Hyunwoo Kim (@v4bel), el mismo investigador que publicó el PoC de Copy Fail — y lo llama directamente su sucesor. Informalmente ya circula como "CopyFail2".

La clase de vulnerabilidad es idéntica: page cache write primitive vía operaciones en-kernel que cruzan límites de memoria. Copy Fail la encontró en el subsistema de criptografía. Dirty Frag la encontró en IPsec y RxRPC. La pregunta que queda en el aire es obvia: ¿cuántos otros subsistemas tienen el mismo patrón?

Lo que diferencia a Dirty Frag de su predecesor es el contexto de la divulgación.

Por qué esto es más urgente que Copy Fail

Copy Fail siguió un proceso de divulgación coordinada prolijo: reportado en marzo, parches en mainline el 1 de abril, CVE asignado el 22, divulgación pública el 29. Cuando el mundo se enteró, los parches ya existían.

Dirty Frag no tuvo esa suerte. Un tercero no relacionado publicó los detalles antes de tiempo, lo que forzó a v4bel a revelar todo públicamente — sin que las distribuciones tuvieran parches listos.

Hoy, 8 de mayo:

  • El parche para el componente ESP fue integrado al árbol upstream de netdev el 7 de mayo.
  • El parche para RxRPC todavía no tiene merge upstream.
  • El PoC funcional es público en GitHub.

Eso es una ventana de exposición activa. Cualquier sistema Linux con esos módulos cargados y sin las mitigaciones aplicadas es vulnerable ahora mismo.

Cómo protegerse

Opción 1: deshabilitar los módulos afectados

Es la mitigación más directa. Antes de aplicarla, verificá si tu sistema usa IPsec:

lsmod | grep -E 'esp4|esp6'

Si no aparece nada (o si no tenés tunnels IPsec activos), podés bloquearlo sin consecuencias:

sudo sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' \
  > /etc/modprobe.d/dirtyfrag.conf"
sudo rmmod esp4 esp6 rxrpc 2>/dev/null; true

Advertencia: deshabilitar esp4/esp6 rompe IPsec/VPN a nivel kernel. Deshabilitar rxrpc afecta clientes AFS. Si usás alguno de esos, pasá a la Opción 2.

Opción 2: deshabilitar namespaces de usuario no privilegiados

Esta mitigación bloquea el vector de ataque sin tocar los módulos:

echo "user.max_user_namespaces=0" | sudo tee /etc/sysctl.d/dirtyfrag.conf
sudo sysctl --system

Corta el acceso que necesita el exploit sin romper IPsec ni RxRPC. Puede afectar herramientas que dependen de user namespaces (Docker rootless, Flatpak, algunos entornos de CI).

Opción 3: actualizar el kernel

Si tu distribución ya tiene parches disponibles, es la solución permanente:

# Ubuntu/Debian
sudo apt update && sudo apt install --only-upgrade linux-image-generic && sudo reboot

# AlmaLinux/RHEL/CentOS
sudo dnf clean metadata && sudo dnf upgrade kernel && sudo reboot

# CloudLinux (KernelCare)
sudo kcarectl --update

Versiones parcheadas conocidas a hoy:

  • CloudLinux 8: kernel-4.18.0-553.123.2.lve.el8 o superior
  • CloudLinux 9: kernel-5.14.0-611.54.3.el9_7 o superior
  • CloudLinux 10: kernel-6.12.0-124.55.2.el10_1 o superior

El parche para RxRPC (CVE-2026-43500) todavía no está en mainline — seguí los avisos de tu distribución para ese componente.

Lo que este patrón sugiere

Dos vulnerabilidades de la misma clase en el mismo mes, en subsistemas distintos, encontradas por la misma persona. Eso no es mala suerte — es un patrón.

La técnica de page cache write primitive via operaciones en-kernel con buffers mal gestionados puede aparecer en otros subsistemas. Copy Fail la encontró en el stack criptográfico. Dirty Frag la encontró en IPsec y RxRPC. El kernel de Linux tiene decenas de subsistemas con rutas de código similares.

Siguiendo el hilo del artículo de Mozilla que publicamos ayer: esto es exactamente el tipo de superficie que la IA va a seguir barriendo. La pregunta no es si habrá más — es cuándo y dónde.

Mientras tanto: parcheá, o al menos aplicá las mitigaciones.

Fuentes: