Se ha descubierto una vulnerabilidad en el kernel de Linux (CVE-2026-46331) que permite a un usuario local sin privilegios obtener acceso root. El fallo ocurre en el subsistema de control de tráfico, permitiendo corromper la memoria caché de archivos críticos sin alterar el disco. Se recomienda actualizar el kernel inmediatamente o deshabilitar los espacios de nombres de usuario no privilegiados.

Un fallo en el subsistema de control de tráfico del kernel de Linux puede permitir que un usuario local sin privilegios obtenga permisos de root en los sistemas afectados.

El CVE-2026-46331 [https://nvd.nist.gov/vuln/detail/CVE-2026-46331], apodado "pedit COW", es una escritura fuera de límites en la acción de edición de paquetes (act_pedit) que corrompe la memoria compartida de la caché de páginas. Un exploit público y funcional [https://github.com/sgkdev/packet_edit_meme] apareció al día siguiente de la asignación del CVE el 16 de junio. Red Hat califica el fallo como importante [https://access.redhat.com/security/vulnerabilities/RHSB-2026-008].

El exploit nunca toca el archivo en el disco. Envenena la copia en caché de un binario setuid root (/bin/su) en la memoria, inyecta una pequeña carga útil y ejecuta esa imagen alterada como root. Los controles de integridad de archivos aparecen limpios mientras una shell de root ya está abierta.

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 otorga al atacante una capacidad de red local al espacio de nombres (CAP_NET_ADMIN) necesaria para activar el error.

En los objetivos de 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 los encabezados de los paquetes en vuelo utilizando una acción llamada pedit. Se supone que la función del kernel que hace esto, tcf_pedit_act(), debe hacer una copia privada de los datos antes de editarlos, el patrón estándar de copia al escribir (copy-on-write).

Comprobó 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 eso sucede, la escritura cae fuera de la región copiada privadamente, por lo que el kernel modifica una página de la caché de páginas compartida en lugar de una copia privada. Si esa página pertenece a un archivo almacenado en caché, la imagen del archivo en memoria se corrompe.

El patrón es 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 posee exclusivamente, y la caché de páginas recibe el impacto.

Lo nuevo aquí es el punto de entrada. Un usuario sin privilegios puede configurar acciones de tc desde dentro de un espacio de nombres de usuario, lo que le otorga el CAP_NET_ADMIN que el exploit necesita.

Sistemas afectados

El autor del PoC informó de una explotación de usuario sin privilegios a root en RHEL 10 y Debian 13 (trixie), donde los espacios de nombres de usuario sin privilegios están abiertos por defecto. Ubuntu 24.04 requirió 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 por defecto porque sus perfiles de AppArmor restringen los espacios de nombres de usuario sin privilegios, aunque el kernel subyacente sigue siendo vulnerable.

Las correcciones varían según el proveedor.

* Debian ha corregido trixie [https://security-tracker.debian.org/tracker/CVE-2026-46331] a través de su canal de seguridad. Debian 11 y 12 todavía figuran como vulnerables.
* Ubuntu enumera las versiones soportadas desde 18.04 hasta 26.04 [https://ubuntu.com/security/CVE-2026-46331] como vulnerables a partir del 25 de junio.
* Red Hat enumera RHEL 8, 9 y 10 como afectados; RHEL 7 no aparece en el boletín.

Qué hacer

Instala el kernel parcheado y reinicia. Prioriza los sistemas donde el "usuario local" no signifique usuario de confianza: hosts multi-inquilino, ejecutores de CI/CD, nodos de Kubernetes, trabajadores de construcción y máquinas de laboratorio o investigación compartidas.

Si aún no puedes parchear, dos mitigaciones anulan la cadena del exploit. En los sistemas que no necesiten reglas de tc pedit, comprueba si el módulo está en uso (lsmod | grep act_pedit) y luego bloquéalo para que no se cargue:

echo 'install act_pedit /bin/true' | sudo tee /etc/modprobe.d/disable-act_pedit.conf

Alternativamente, desactiva los espacios de nombres de usuario sin privilegios (user.max_user_namespaces=0 en RHEL, kernel.unprivileged_userns_clone=0 en Debian/Ubuntu). Eso elimina la capacidad local del espacio de nombres que el exploit necesita, pero rompe los contenedores sin root, algunos sandboxes de CI y navegadores con sandbox. Pruébalo primero.

Debido a que la sobrescritura se dirige a la memoria en caché, es posible que los controles de integridad de archivos no lo detecten. Vaciar la caché de páginas (echo 3 > /proc/sys/vm/drop_caches) limpia la copia envenenada en memoria, pero no hace nada respecto a la shell de root que el atacante ya abrió. Trata el host como comprometido.

La corrección llegó a la lista de correo de netdev [https://lists.openwall.net/netdev/2026/05/23/133] a finales de mayo, presentada como un parche rutinario de corrupción de datos. El detalle explotable estuvo en una lista de correo pública durante semanas. Sin CVE, sin advertencia de seguridad. El CVE fue asignado cuando la corrección se fusionó el 16 de junio. La prueba de concepto convertida en arma siguió al día siguiente. Para los errores de corrupción de la caché de páginas del kernel, esperar a que haya una regla de escáner es demasiado lento.

Fuente:
THN