Una falla en el subsistema de control de tráfico del kernel de Linux puede permitir que un usuario local sin privilegios obtenga root en los sistemas afectados.
CVE-2026-46331, apodado “pedit VACA,” es una escritura fuera de 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ó un día después de la asignación de CVE el 16 de junio. Red Hat califica la falla como importante.
El exploit nunca toca el archivo en el disco. Envenena la copia almacenada en caché de un binario raíz setuid (/bin/su) en la memoria, inyecta una pequeña carga útil y ejecuta esa imagen alterada como raíz. Las comprobaciones de integridad de archivos resultan limpias mientras ya hay un shell raíz abierto.
El exploit necesita dos cosas: que act_pedit sea cargable y que los espacios de nombres de usuario sin privilegios estén abiertos, lo que le da al atacante una capacidad de red local de espacio de nombres (CAP_NET_ADMIN) necesaria para desencadenar el error.
En los objetivos RHEL y Debian probados, ambas condiciones estaban presentes.
Cómo funciona el error
La herramienta de control de tráfico tc de Linux puede reescribir encabezados de paquetes en vuelo mediante una acción llamada pedit. Se supone que la función del núcleo que hace esto, tcf_pedit_act(), debe hacer una copia privada de los datos antes de editarlos, el patrón estándar de copia en escritura.
Verificó el rango de escritura una vez, antes de que se conocieran las compensaciones finales. Algunas claves de edición solo resuelven su desplazamiento en tiempo de ejecución. Cuando eso sucede, la escritura aterriza fuera de la región copiada de forma privada, 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 almacenado en caché, la imagen en memoria del archivo está dañada.
El patrón me resulta familiar. 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 es de su propiedad exclusiva y el caché de la página recibe el impacto.
Lo nuevo 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 proporciona el CAP_NET_ADMIN que necesita el exploit.
Sistemas afectados
El autor de PoC informó sobre una explotación sin privilegios de root en RHEL 10 y Debian 13 (trixie), donde los espacios de nombres de usuarios sin privilegios están abiertos de forma predeterminada. Ubuntu 24.04 requería la ejecución de enrutamiento a través de perfiles de AppArmor que aún permiten espacios de nombres de usuario. Ubuntu 26.04 bloquea esa ruta de forma predeterminada porque sus perfiles de AppArmor restringen los espacios de nombres de usuarios sin privilegios, aunque el kernel subyacente sigue siendo vulnerable.
Las correcciones se dividen por proveedor.
- Debian ha solucionado trixie a través de su canal de seguridad. Debian 11 y 12 todavía figuran como vulnerables.
- Ubuntu enumera las versiones compatibles desde 18.04 hasta 26.04 como vulnerables a partir del 25 de junio.
- Red Hat enumera RHEL 8, 9 y 10 como afectados; RHEL 7 no figura en el boletín.
Qué hacer
Instale el kernel parcheado y reinicie. Priorice los sistemas donde “usuario local” no significa usuario confiable: hosts multiinquilino, ejecutores de CI/CD, nodos de Kubernetes, trabajadores de compilación y máquinas de laboratorio o de investigación compartidas.
Si aún no puede parchear, dos mitigaciones acaban con la cadena de exploits. En sistemas que no necesitan reglas tc pedit, verifique si el módulo está en uso (lsmod | grep act_pedit), luego bloquee su carga:
echo 'install act_pedit /bin/true' | sudo tee /etc/modprobe.d/disable-act_pedit.conf
Alternativamente, deshabilite los espacios de nombres de usuarios sin privilegios (user.max_user_namespaces=0 en RHEL, kernel.unprivileged_userns_clone=0 en Debian/Ubuntu). Esto elimina la capacidad de espacio de nombres local que necesita el exploit, pero rompe los contenedores sin raíz, algunos entornos limitados de CI y navegadores en entornos aislados. Prueba primero.
Debido a que la sobrescritura tiene como objetivo la memoria caché, es posible que las comprobaciones de integridad de archivos no la detecten. Al eliminar el caché de la página (echo 3 > /proc/sys/vm/drop_caches) se borra la copia en memoria envenenada, pero no se hace nada con respecto al shell raíz que el atacante ya abrió. Trate al host como comprometido.
La solución llegó a la lista de correo de netdev a finales de mayo, enmarcada 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 se fusionó la solución el 16 de junio. La prueba de concepto armada siguió en un día. Para los errores de corrupción de la caché de páginas del kernel, esperar una regla de análisis es demasiado lento.