DirtyDecrypt PoC eleva el riesgo de escalada de privilegios en kernels cercanos al mainline

Una prueba de concepto pública que aprovecha una vulnerabilidad recientemente corregida en el módulo rxgk del kernel Linux eleva el riesgo para sistemas que ejecutan kernels muy próximos al árbol principal: el exploit denominado DirtyDecrypt (o DirtyCBC) permite a un atacante con acceso local convertirse en root en determinadas configuraciones del sistema.

La raíz técnica del problema, según los investigadores que publicaron el PoC, es una escritura en pagecache ocasionada por la falta de una comprobación de copia‑on‑write (COW) en la función rxgk_decrypt_skb: en términos sencillos, código del kernel terminó escribiendo donde no debía sobre datos compartidos, lo que abre la puerta a escalada de privilegios. El equipo V12 publicó el PoC y explica los detalles en su repositorio (V12 PoC: DirtyDecrypt), y la descripción encaja con la corrección registrada en el NVD como CVE-2026-31635.

Es importante subrayar dos factores que matizan el impacto: primero, la explotación requiere que el kernel esté compilado con la opción CONFIG_RXGK habilitada (es decir, soporte RxGK para AFS/rxrpc); por tanto, solo afecta a distribuciones que siguen de cerca el kernel upstream —por ejemplo Fedora, Arch o openSUSE Tumbleweed— o a sistemas con kernels personalizados que incluyan ese módulo. Segundo, el vector es local: un atacante necesita ejecutar código en la máquina previamente (por ejemplo, a través de una cuenta de usuario comprometida o un proceso malicioso con capacidades limitadas) para escalar a root.

La existencia de un PoC público cambia el umbral de riesgo: antes era una falla corregida en upstream, ahora cualquier adversario con acceso local y conocimientos básicos podría reutilizar la prueba para tomar control total del sistema si el parche no está aplicado. Este patrón no es nuevo: en las últimas semanas han aparecido fallos de escalada raíz de la misma familia (Dirty Frag, Fragnesia, Copy Fail) y organismos como la CISA ya han advertido y listado vulnerabilidades explotadas en el catálogo conocido (CISA Known Exploited Vulnerabilities), lo que evidencia una oleada de explotación activa contra vectores de kernel.

Qué deben hacer administradores y usuarios: actualizar el kernel a la versión que contiene la corrección lo antes posible; para entornos de producción donde la actualización inmediata no sea práctica, aplicar mitigaciones temporales y controlar el acceso local. Una mitigación utilizada anteriormente contra fallos similares consiste en evitar la carga de los módulos involucrados creando una regla en /etc/modprobe.d que impida su instalación, descargando los módulos y vaciando caches; tenga en cuenta que esta medida puede romper IPsec y sistemas de archivos distribuidos AFS. Si la adopta, pruebe primero en entornos controlados y comprenda el impacto sobre conectividad y servicios.

Además de parchear o mitigar, revise la telemetría y la integridad del sistema: busque signos de escalada de privilegios o persistencia (sesiones root inesperadas, binarios SUID nuevos, procesos anómalos con UID 0, cambios en /etc, entradas sospechosas en dmesg o syslog). Si tiene detección en kernel o EDR, compruebe eventos relacionados con rxgk o operaciones de pagecache atípicas; si no dispone de estas herramientas, considere desplegar controles que limiten el acceso local y mejorar la segmentación de usuarios y servicios.

Para equipos que gestionan flotas grandes, valore aplicar backports de seguridad ofrecidos por la distribución, utilizar servicios de livepatch donde estén disponibles y priorizar la actualización de kernels en bastiones o máquinas con cuentas de múltiples usuarios. Mantenga un proceso de respuesta que incluya aislamiento de hosts sospechosos, recolección de pruebas y restauración desde respaldos conocidos limpios cuando sea necesario.

La divulgación responsable y las pruebas públicas también nos recuerdan una lección operativa: las vulnerabilidades en el espacio de kernel, aunque locales, son muy valiosas para atacantes con acceso inicial y aceleran el movimiento lateral y la persistencia. Revisar las opciones de compilación del kernel en máquinas críticas (por ejemplo, consultando la configuración del kernel o los paquetes del proveedor para ver si CONFIG_RXGK está activo) ayuda a priorizar parches y mitigaciones con criterio técnico.

Si quiere profundizar en los recursos técnicos y los avisos originales, consulte el PoC del equipo V12 en GitHub (https://github.com/v12-security/pocs/tree/main/dirtydecrypt) y la entrada del NVD para la corrección (https://nvd.nist.gov/vuln/detail/CVE-2026-31635). Para políticas y seguimiento de fallos explotados en el ecosistema, la base de CISA es una referencia útil (https://www.cisa.gov/known-exploited-vulnerabilities-catalog).

En resumen: parchear ya, reducir acceso local no esencial, monitorear indicadores de compromiso y preparar un plan de respuesta. La disponibilidad pública de PoC obliga a asumir que, sin mitigación o corrección, la probabilidad de explotación aumentará rápidamente.