Detalles de la vulnerabilidad
Una falla en el subsistema de control de tráfico del kernel de Linux puede permitir que un usuario local sin privilegios obtenga acceso root en sistemas afectados. La vulnerabilidad, identificada como CVE-2026-46331 y apodada 'pedit COW', es una escritura fuera de los límites en la acción de edición de paquetes (act_pedit) que corrompe la memoria caché de página compartida. Un exploit público y funcional apareció dentro de las 24 horas posteriores a la asignación del CVE el 16 de junio. Red Hat clasifica la falla como importante.
El exploit nunca toca el archivo en disco. Envenena la copia en caché de un binario setuid root (/bin/su) en memoria, inyecta una pequeña carga útil y ejecuta esa imagen alterada como root. Las comprobaciones de integridad de archivos resultan limpias mientras ya hay una shell root abierta. El exploit requiere dos condiciones: que act_pedit se pueda cargar y que los espacios de nombres de usuario no privilegiados estén habilitados, lo que otorga al atacante la capacidad de red local (CAP_NET_ADMIN) necesaria para activar el bug.
Funcionamiento del bug
La herramienta tc de control de tráfico de Linux puede reescribir encabezados de paquetes en vuelo mediante una acción llamada pedit. La función del kernel que realiza esto, tcf_pedit_act(), debería hacer una copia privada de los datos antes de editarlos, siguiendo el patrón estándar de copia en escritura. Sin embargo, verificaba el rango escribible una vez, antes de que se conocieran los desplazamientos finales. Algunas claves de edición solo resuelven su desplazamiento en tiempo de ejecución. Cuando esto ocurre, la escritura se realiza fuera de la región copiada privadamente, por lo que el kernel modifica una página de caché de página compartida en lugar de una copia privada. Si esa página pertenece a un archivo en caché, la imagen en memoria del archivo se corrompe.
El patrón es conocido: Dirty Pipe, Copy Fail, DirtyClone y Dirty Frag comparten la misma forma: una ruta rápida del kernel escribe en una página que no posee exclusivamente, y la caché de página sufre las consecuencias. Lo novedoso aquí es el punto de entrada. Un usuario sin privilegios puede configurar acciones tc desde dentro de un espacio de nombres de usuario, lo que le otorga el CAP_NET_ADMIN necesario para el exploit.
Sistemas afectados
El autor de la prueba de concepto reportó explotación exitosa de no privilegiado a root en RHEL 10 y Debian 13 (trixie), donde los espacios de nombres de usuario no privilegiados están habilitados por defecto. En Ubuntu 24.04 era necesario enrutar la ejecución a través de perfiles de AppArmor que aún permiten espacios de nombres de usuario. Ubuntu 26.04 bloquea esa ruta por defecto porque sus perfiles de AppArmor restringen los espacios de nombres de usuario no privilegiados, aunque el kernel subyacente sigue siendo vulnerable.
Las correcciones varían según el distribuidor. Debian ha corregido trixie a través de su canal de seguridad. Debian 11 y 12 aún figuran como vulnerables. Ubuntu lista las versiones compatibles desde 18.04 hasta 26.04 como vulnerables a partir del 25 de junio. Red Hat lista RHEL 8, 9 y 10 como afectados; RHEL 7 no aparece en el boletín.
Recomendaciones
Instale el kernel parcheado y reinicie. Priorice sistemas donde 'usuario local' no signifique usuario confiable: hosts multiinquilino, runners de CI/CD, nodos de Kubernetes, trabajadores de compilación y máquinas de laboratorio o investigación compartidas. Si no puede parchear aún, dos mitigaciones rompen la cadena del exploit. En sistemas que no necesitan reglas tc pedit, verifique si el módulo está en uso (lsmod | grep act_pedit) y luego bloquee su carga. Alternativamente, deshabilite los espacios de nombres de usuario no privilegiados (user.max_user_namespaces=0 en RHEL, kernel.unprivileged_userns_clone=0 en Debian/Ubuntu). Esto elimina la capacidad local del espacio de nombres que necesita el exploit, pero rompe contenedores sin root, algunos entornos aislados de CI y navegadores con sandbox. Pruebe primero.
Debido a que la sobrescritura se dirige a la memoria en caché, las comprobaciones de integridad de archivos pueden no detectarla. Vaciar la caché de página (echo 3 > /proc/sys/vm/drop_caches) elimina la copia en memoria envenenada, pero no hace nada respecto a la shell root que el atacante ya abrió. Trate el host como comprometido. La corrección llegó a la lista de correo netdev a finales de mayo, presentada como un parche rutinario de corrupción de datos. El detalle explotable permaneció en una lista de correo pública durante semanas. Sin CVE, sin advertencia de seguridad. El CVE se asignó cuando la corrección se fusionó el 16 de junio. La prueba de concepto armada siguió en menos de un día. Para los bugs de corrupción de caché de página del kernel, esperar una regla de escáner es demasiado lento.
Deja una respuesta