Se ha publicado un código de prueba de concepto (PoC) para DirtyDecrypt (también conocido como DirtyCBC), una vulnerabilidad de alta gravedad en el núcleo de Linux. Este fallo, identificado como CVE-2026-31635, permite que atacantes locales obtengan acceso total de root en los sistemas afectados. El parche para corregir este problema fue integrado discretamente el 25 de abril de 2026.

Un exploit de prueba de concepto (PoC) funcional para una vulnerabilidad de escalada de privilegios locales del kernel de Linux de severidad alta, apodada DirtyDecrypt (también rastreada como DirtyCBC), permite que atacantes locales obtengan acceso total de root en los sistemas afectados.

El analista de seguridad Will Dormann atribuye técnicamente el fallo al CVE-2026-31635, cuyo parche se fusionó discretamente en la rama principal el 25 de abril de 2026.

DirtyDecrypt reside en la función rxgk_decrypt_skb() dentro del subsistema RxGK del kernel de Linux, la capa de seguridad basada en GSS-API para RxRPC, el transporte de red utilizado por el cliente Andrew File System (AFS).

Moselwal señaló que la causa raíz es la falta de una protección de copia en escritura (COW): al descifrar un búfer de socket entrante (sk_buff), el kernel escribe directamente en una página compartida de la caché de páginas sin crear primero una copia privada.

Esta escritura sin protección cae en la memoria perteneciente a procesos privilegiados o en la caché de páginas de archivos privilegiados, incluidos /etc/shadow, /etc/sudoers o binarios SUID, lo que permite que un usuario local sin privilegios corrompa y, en última instancia, sobrescriba esas páginas para lograr acceso de root.

V12 describió su hallazgo como "escritura de pagecache rxgk debido a la falta de protección COW en rxgk_decrypt_skb" y lo informó a los mantenedores del kernel el 9 de mayo de 2026, solo para que le dijeran que era un duplicado de un problema interno ya parcheado.

Distribuciones Afectadas por DirtyDecrypt

La explotación requiere un kernel de Linux compilado con CONFIG_RXGK=y o CONFIG_RXGK=m. En la práctica, esto afecta a las distribuciones de lanzamiento continuo (rolling-release) que siguen de cerca el desarrollo del kernel upstream:

• Fedora (incluyendo Rawhide y Workstation, antes del parche)
• Arch Linux (antes de ejecutar pacman -Syu)
• openSUSE Tumbleweed (antes de ejecutar zypper dup)
• Sistemas que utilizan PPA del kernel mainline o kernel-ml de ELRepo en RHEL/CentOS Stream

Las distribuciones empresariales estables —Debian Stable, RHEL 8/9 y Ubuntu LTS— se distribuyen con RxGK desactivado y, por lo general, no se ven afectadas por defecto. Puedes verificar si estás expuesto ejecutando:

bashzcat /proc/config.gz | grep RXGK

La amenaza operativa aumenta significativamente en entornos de contenedores. En un nodo trabajador de Kubernetes que ejecute un kernel de lanzamiento continuo, una explotación exitosa de DirtyDecrypt se encadena en un escape total del contenedor: el acceso root local en el host otorga acceso a cada pod, a cada socket de tiempo de ejecución de contenedores y a cada secreto de Kubernetes montado en ese nodo, añadió Moselwal.

Las estaciones de trabajo de desarrolladores en Fedora o Arch que comúnmente contienen contextos de kubectl activos, perfiles de producción de AWS y claves SSH representan los objetivos de mayor riesgo en entornos empresariales.

DirtyDecrypt es la cuarta LPE del kernel de Linux en la misma superficie de ataque XFRM/ESP/rxgk en tres semanas, perteneciendo a la misma clase de vulnerabilidad que la familia Copy Fail, la cual ha sido explotada activamente.

Mitigaciones

La remediación principal es instalar la actualización del kernel que contiene el parche del 25 de abril:

bash# Fedora
sudo dnf upgrade --refresh kernel kernel-core kernel-modules && sudo systemctl reboot

# Arch Linux
sudo pacman -Syu linux linux-headers && sudo systemctl reboot

# openSUSE Tumbleweed
sudo zypper dup && sudo systemctl reboot

Para los sistemas donde el parcheo no es posible de inmediato, poner en lista negra los módulos del kernel rxrpc, esp4 y esp6 proporciona una solución temporal, aunque esto romperá las conexiones VPN IPsec y los montajes de AFS.

Los operadores de Kubernetes deben reconstruir las imágenes de los nodos trabajadores con el kernel parcheado y aplicar estándares de seguridad de pods (perfil restricted) en todo el clúster, asegurando que allowPrivilegeEscalation: false esté configurado por defecto en todas las cargas de trabajo.

Si eres usuario de Linux en Fedora, Arch o openSUSE Tumbleweed, deberías tratar esto como una prioridad inmediata dada la disponibilidad de código PoC público y el precedente de explotación establecido por la vulnerabilidad Copy Fail estrechamente relacionada.

Fuentes:
https://cybersecuritynews.com/dirtydecrypt-linux-kernel-vulnerability/