Dirty Frag (CVE-2026-43284): cómo Core-Admin detecta y mitiga el fallo del kernel Linux

#1

Dirty Frag (CVE-2026-43284): cómo Core-Admin detecta y mitiga el fallo del kernel Linux

Introducción

Dirty Frag es una vulnerabilidad crítica del kernel Linux divulgada el 7 de mayo de 2026 que permite a un usuario local sin privilegios obtener root con un solo comando en prácticamente todas las distribuciones Linux modernas. Se trata en realidad de una cadena de dos CVE:

  • CVE-2026-43284 — afecta a los módulos esp4 y esp6 (IPsec ESP).
  • CVE-2026-43500 — afecta al módulo rxrpc (transporte AFS / Kerberos RxRPC).

Pertenece a la misma familia que Dirty Pipe y CopyFail: una primitiva determinista de escritura sobre la page cache del kernel que, dirigida contra un binario setuid (su, sudo, passwd), entrega root inmediato.

Existe PoC público funcional desde el día de la divulgación, por lo que cualquier servidor Linux sin parchear es un objetivo real, no teórico. Mientras los parches del kernel llegan a través de los canales habituales de cada distribución, Core-Admin aplica de forma automática una mitigación efectiva que cierra el camino de explotación sin necesidad de reiniciar.

Este artículo explica cómo funciona el fallo, a qué distribuciones afecta y cómo Core-Admin lo gestiona a través del checker security_and_mitigations.

Cómo funciona el fallo

Los caminos rápidos de descifrado in-place de esp4, esp6 y rxrpc operan directamente sobre las páginas que llegan en un sk_buff. El problema aparece cuando esas páginas no son propiedad exclusiva del kernel, sino que han sido enganchadas desde espacio de usuario mediante:

  • splice(2)
  • sendfile(2)
  • MSG_SPLICE_PAGES

En ese escenario, el kernel descifra (sobrescribe) directamente sobre páginas que un proceso sin privilegios todavía referencia. El atacante consigue:

  1. Observar el texto plano del paquete recibido (filtración).
  2. Provocar una escritura controlada en la page cache de un fichero cualquiera, incluido un binario setuid que pertenece a root.

El paso 2 es el que entrega root: corromper su o sudo y ejecutarlo es suficiente. La técnica es idéntica a la de Dirty Pipe (CVE-2022-0847) y CopyFail (CVE-2026-31431), con la diferencia de que la primitiva de escritura procede del subsistema de red (ESP / RxRPC) en lugar del subsistema de criptografía o de pipes.

Nota sobre las dos CVE: aunque son fallos independientes, la recomendación oficial de Red Hat, Ubuntu, AlmaLinux y los investigadores de Wiz es mitigar las dos a la vez: deshabilitar solo esp4/esp6 o solo rxrpc deja el sistema explotable por la otra vía.

Distribuciones afectadas

La ventana de introducción de cada fallo es distinta:

  • esp4 / esp6 (ESP): vulnerable desde 2017 aproximadamente. En la práctica, cualquier kernel ≥ 4.x en uso real está afectado.
  • rxrpc: vulnerable desde 2023 aproximadamente. Kernels 5.x tardíos / 6.x. RHEL 8 (kernel 4.18) no distribuye rxrpc en stock; RHEL 9 / AlmaLinux 9 solo lo incluyen vía kernel-modules-partner.

A continuación, el estado para las distribuciones soportadas por Core-Admin:

Distribución Kernel típico esp4/esp6 (ESP) rxrpc Notas
debian-lenny / squeeze / wheezy 2.6.x / 3.2 NO (pre-2017) NO EOL
debian-jessie 3.16 NO (pre-2017) NO EOL
ubuntu-precise (12.04) 3.2 / 3.13 NO (pre-2017) NO EOL
centos-63 2.6.32 NO (pre-2017) NO EOL
ubuntu-xenial (16.04) 4.4 / 4.15 HWE DEPENDE NO Stock 4.4 frontera; HWE 4.15+ SÍ ESP
centos-7 3.10 (RHEL) DEPENDE NO Verificar changelog del kernel
debian-stretch 4.9 PROBABLEMENTE SÍ NO LTS-EOL
ubuntu-bionic (18.04) 4.15 / 5.4 HWE SÍ NO ESM activo
debian-buster 4.19 SÍ NO LTS
ubuntu-focal (20.04) 5.4 / 5.15 HWE SÍ DEPENDE rxrpc alcanzable en HWE
debian-bullseye 5.10 SÍ borderline rxrpc emergió ~2023
ubuntu-jammy (22.04) 5.15 / 6.5 HWE SÍ SÍ (HWE)
debian-bookworm 6.1 SÍ SÍ Stable actual
ubuntu-noble (24.04) 6.8 SÍ SÍ LTS actual

El checker no se basa en una lista hardcodeada de distros, sino en una detección dinámica que combina la versión del kernel con la presencia y la posibilidad de carga real de cada módulo. Las casillas “DEPENDE” / “borderline” se resuelven solas en cada servidor.

Cómo lo mitiga Core-Admin

Core-Admin incluye el checker security_and_mitigations, diseñado como un punto único donde se concentran las detecciones y mitigaciones de fallos críticos del kernel mientras llegan los parches oficiales. Este checker ya cubría CopyFail (CVE-2026-31431) y ahora también Dirty Frag.

Estrategia de mitigación

Siguiendo la recomendación de Red Hat, Ubuntu, AlmaLinux y Wiz, la mitigación bloquea los tres módulos a la vez (esp4, esp6, rxrpc). La acción se compone de dos pasos:

  1. Despliegue de /etc/modprobe.d/disable-dirty-frag.conf con el siguiente contenido:

    install esp4 /bin/true
install esp6 /bin/true
install rxrpc /bin/true

blacklist esp4
blacklist esp6
blacklist rxrpc

    La directiva blacklist por sí sola no es suficiente: solo bloquea la carga en arranque. La autoload que dispara request_module() cuando llega un paquete ESP o se abre un socket rxrpc seguiría funcionando. La regla install ... /bin/true sustituye la carga del módulo por un no-op, cerrando ese camino.

  2. rmmod de cada módulo si está cargado, en modo best-effort. Si un módulo está ocupado (poco frecuente en servidores típicos), la regla modprobe.d ya bloquea futuras cargas; el verificador avisa con CRITICAL si tras la mitigación alguno sigue cargado, indicando que se requiere reinicio.

Coste funcional de la mitigación

Software / rol ¿Afectado por el bloqueo? Notas
Apache, Nginx (HTTPS sobre OpenSSL) No TLS no usa ESP
Postfix, Dovecot, Exim (TLS) No
MySQL/MariaDB TLS No
OpenSSH, rsync sobre SSH No
OpenVPN No No usa ESP del kernel
WireGuard No Protocolo propio, no ESP
strongSwan / libreswan (IPsec ESP) SÍ Activar skip_dirty_frag_mitigation
Clientes AFS / kAFS SÍ (rxrpc) Muy raro en hosting
Samba No
BEEP / Vortex (transporte de Core-Admin) No TLS

A efectos prácticos, en un servidor típico de hosting / correo / web, bloquear esp4/esp6/rxrpc es una operación de riesgo cero. La única excepción real son los hosts que terminan túneles IPsec ESP (strongSwan, libreswan).

Lógica de detección

detect_dirty_frag() clasifica cada uno de los tres módulos en uno de cuatro estados:

  • loaded: el módulo está cargado en memoria (vulnerable).
  • autoloadable: el módulo no está cargado pero modprobe -n -v lo cargaría a demanda (vulnerable).
  • blocked: existe una regla install ... que bloquea la autoload (no vulnerable).
  • absent: el módulo no está disponible en este kernel (no vulnerable).

El sistema se considera vulnerable si al menos uno de los tres módulos está en loaded o autoloadable. Cualquier comando que reemplace el insmod (/bin/true, /bin/false, /bin/:) cuenta como bloqueo válido — esto permite que coexista con reglas escritas por otras herramientas de hardening o por la propia distribución.

Lógica de verificación

verify_dirty_frag() confirma tres invariantes independientes tras aplicar la mitigación:

  1. /etc/modprobe.d/disable-dirty-frag.conf existe y contiene las tres reglas install.
  2. Ninguno de esp4, esp6, rxrpc aparece en lsmod.
  3. modprobe -n -v para cada módulo está bloqueado (o el módulo no existe en este kernel).

Si alguno falla, el checker devuelve CRITICAL indicando exactamente qué invariante no se cumple.

Salida del checker

En una máquina no vulnerable (mitigación ya aplicada o módulos no presentes):

[OK] Dirty Frag (CVE-2026-43284): system not vulnerable
     (kernel 6.8.0, esp4/esp6/rxrpc all autoload-blocked)

En una máquina vulnerable donde Core-Admin acaba de aplicar la mitigación:

[OK] Dirty Frag (CVE-2026-43284): vulnerable, mitigation applied and verified
     (modprobe.d rules; esp4/esp6/rxrpc unloaded; dry-run blocked)

En una máquina mixta (p. ej. RHEL 8 sin rxrpc en stock):

[OK] Dirty Frag (CVE-2026-43284): system not vulnerable
     (kernel 4.18.0, esp4/esp6 autoload-blocked; rxrpc absent)

Opción de exclusión: skip_dirty_frag_mitigation

Para servidores que terminan IPsec ESP (strongSwan / libreswan), el bloqueo de esp4/esp6 rompe la VPN. En ese caso, Core-Admin expone la opción skip_dirty_frag_mitigation desde la configuración del checker:

  • Por defecto: false → la mitigación se aplica.
  • Si se activa: la detección sigue ejecutándose, pero no se aplica la mitigación. El checker devuelve OK con el mensaje informativo “Dirty Frag (CVE-2026-43284) detected, system vulnerable but mitigation skipped”.

Esto permite que el operador documente conscientemente el riesgo residual en hosts que dependen de IPsec, mientras espera el kernel parcheado de su distribución.

Verificación manual

Si quieres comprobar manualmente el estado de un servidor sin pasar por el checker, puedes ejecutar:

# 1. Versión del kernel
uname -r

# 2. ¿Hay alguno de los módulos cargado?
lsmod | grep -E '^(esp4|esp6|rxrpc)\b' || echo "ningún módulo cargado"

# 3. ¿La autoload está bloqueada?
for m in esp4 esp6 rxrpc; do
  echo -n "$m: "
  modprobe -n -v "$m" 2>&1 | grep -q '/bin/true\|/bin/false\|/bin/:' \
    && echo "blocked" \
    || echo "AUTOLOAD ABIERTA - VULNERABLE"
done

# 4. ¿Existe el fichero de mitigación de Core-Admin?
test -f /etc/modprobe.d/disable-dirty-frag.conf \
  && echo "mitigación Core-Admin presente" \
  || echo "mitigación Core-Admin NO desplegada"

Aplicar la mitigación a mano (sin Core-Admin)

Si el checker no se puede ejecutar por algún motivo, los pasos manuales son:

# 1. Bloquear cargas futuras
cat > /etc/modprobe.d/disable-dirty-frag.conf <<'EOF'
install esp4 /bin/true
install esp6 /bin/true
install rxrpc /bin/true

blacklist esp4
blacklist esp6
blacklist rxrpc
EOF
chmod 0644 /etc/modprobe.d/disable-dirty-frag.conf

# 2. Descargar los módulos si están actualmente cargados
for m in esp4 esp6 rxrpc; do
  lsmod | awk '{print $1}' | grep -qx "$m" && rmmod "$m"
done

# 3. Verificar
for m in esp4 esp6 rxrpc; do
  modprobe -n -v "$m" 2>&1 | grep -q '/bin/true' && echo "$m blocked"
done
lsmod | grep -E '^(esp4|esp6|rxrpc)\b' || echo "ningún módulo cargado"

Revertir la mitigación tras el kernel parcheado

Cuando la distribución publique el kernel corregido y el servidor se haya reiniciado sobre la versión nueva, conviene retirar la mitigación para que esp4/esp6/rxrpc vuelvan a estar disponibles:

rm /etc/modprobe.d/disable-dirty-frag.conf
# La siguiente operación que necesite cualquiera de los módulos los cargará normalmente.

En la próxima ejecución, el checker reportará OK con “system not vulnerable” basándose en que la autoload vuelve a estar abierta pero el kernel ya no contiene la primitiva vulnerable.

Preguntas frecuentes

P: ¿Necesito reiniciar el servidor para que la mitigación surta efecto?

No. La mitigación es efectiva inmediatamente: el fichero modprobe.d bloquea cualquier carga futura, y rmmod descarga los módulos en caliente. Solo se requiere reinicio si algún módulo está ocupado en el momento de la mitigación (caso muy poco habitual en servidores típicos), y el propio checker lo indica con CRITICAL.

P: ¿La mitigación rompe mi servidor web / correo / base de datos?

No. Apache, Nginx, Postfix, Dovecot, Exim, MySQL/MariaDB, PHP, OpenSSH, OpenVPN, WireGuard y Samba no usan los módulos esp4/esp6/rxrpc. La mitigación es transparente para todos ellos.

P: ¿Cuándo NO debo aplicar la mitigación automática?

Si tu servidor termina túneles IPsec ESP (strongSwan / libreswan), bloquear esp4/esp6 romperá la VPN. En ese caso, activa la opción skip_dirty_frag_mitigation en la configuración del checker. Core-Admin seguirá detectando que el host es vulnerable pero no aplicará el bloqueo, dejando la decisión en manos del operador hasta que llegue el kernel parcheado.

P: ¿Qué pasa si mi distribución ya incluye una mitigación oficial?

El checker reconoce reglas install con cualquier comando no-op (/bin/true, /bin/false, /bin/:). Si la propia distribución ha desplegado un fichero de hardening con una de esas reglas, Core-Admin lo detectará como mitigación válida y reportará OK sin escribir su propio fichero.

P: ¿La mitigación afecta a WireGuard u OpenVPN?

No. WireGuard implementa su propio protocolo en el kernel (módulo wireguard) y no usa ESP. OpenVPN trabaja en espacio de usuario con TLS sobre UDP/TCP y tampoco depende de los módulos afectados. Ambos siguen funcionando con normalidad.

P: ¿Cómo puedo saber si mi sistema fue explotado antes de aplicar la mitigación?

La detección post-mortem es difícil porque el ataque no deja rastros obvios en logs. La indicación más fiable es revisar la integridad de los binarios setuid críticos (/usr/bin/su, /usr/bin/sudo, /usr/bin/passwd) comparando sus checksums con los del paquete original:

# Debian / Ubuntu
debsums /usr/bin/su /usr/bin/sudo /usr/bin/passwd

# RHEL / CentOS / AlmaLinux
rpm -V coreutils sudo passwd

Cualquier diferencia inesperada en estos binarios es un indicador serio.

P: ¿Tengo que volver a ejecutar el checker manualmente?

No. Core-Admin ejecuta los checkers periódicamente como parte del ciclo normal de monitorización. La mitigación se aplica en la primera pasada sobre cada servidor afectado, y a partir de ahí las pasadas siguientes simplemente verifican que sigue en su sitio.

Referencias