Probado en Talos Linux (que incluye CONFIG_BPF_LSM=y y bpf en la pila LSM predeterminada desde v1.10), funciona en cualquier distribución con la misma configuración de kernel.

Por qué

Copy Fail (CVE-2026-31431) es un fallo lógico en algif_aead que permite a un usuario local sin privilegios realizar una escritura de 4 bytes en la caché de páginas de cualquier binario setuid, logrando root con un script Python de 732 bytes. El exploit solo necesita AF_ALG + splice(), ambos accesibles desde cualquier proceso sin privilegios por defecto. El fix en mainline es a664bf3d603d.

Dirty Frag es una clase de vulnerabilidad posterior divulgada en mayo de 2026 por la misma línea de investigación. Encadena dos bugs que "ensucian" el miembro frag de sk_buff — xfrm-ESP Page-Cache Write y RxRPC Page-Cache Write. La variante RxRPC realiza un descifrado pcbc(fcrypt) in-place sobre una página de caché de páginas fijada con splice() dentro de rxkad_verify_packet_1() y alcanza root sin necesidad de crear namespaces de usuario, lo que la convierte en la mitad más explotable universalmente de la cadena en distribuciones endurecidas. El fix de xfrm-ESP llegó a netdev como f4c50a4034e6 (2026-05-07); las distribuciones aún están haciendo backport al momento de escribir esto, y RxRPC no tiene fix público todavía — consulta el write-up upstream para la cronología de divulgación.

Ambos exploits dependen de abrir un socket en la familia afectada. Hasta que los fixes del kernel lleguen a tu distribución, la superficie de ataque se puede eliminar impidiendo que el espacio de usuario cree sockets AF_ALG o AF_RXRPC. Comparado con las alternativas:

Este proyecto es la opción sin reinicio. Ejecútalo en todo el clúster y luego planifica los fixes permanentes del kernel en tu cadencia habitual de parches.

Nota sobre la variante ESP de Dirty Frag. La mitad xfrm-ESP Page-Cache Write de Dirty Frag no se cierra con este DaemonSet — se activa a través de netlink XFRM + UDP_ENCAP_ESPINUDP, no mediante una familia de sockets dedicada, y un filtro BPF-LSM limpio para ella rompería el IPsec legítimo en el host o requeriría lógica consciente de namespaces de usuario. Actualmente no se rastrea aquí — se aceptan contribuciones. En distribuciones endurecidas que bloquean namespaces de usuario sin privilegios (p. ej. la política AppArmor predeterminada de Ubuntu), la variante ESP es inalcanzable de todos modos y el bloqueo de RxRPC aquí es suficiente.

Cómo funciona

bpf/blocker.c es un programa BPF-LSM corto:

El cargador Go (main.go, ~40 líneas) carga el programa y lo adjunta mediante bpf(BPF_LINK_CREATE). El enlace se mantiene durante toda la vida del pod. En SIGTERM, el enlace se cierra y el hook se desadjunta.

Requiere un kernel compilado con CONFIG_BPF_LSM=y y bpf en la pila LSM activa (lsm=...,bpf en la línea de comandos del kernel). Talos Linux incluye ambos habilitados por defecto desde v1.10.

Instalación

kubectl

Para el último commit en main (puede incluir cambios no publicados):

Helm

El chart no se publica como artefacto OCI (la ruta del registro se comparte con la imagen del contenedor). Instala desde un checkout etiquetado:

O mediante los atajos del Makefile:

El DaemonSet debe ejecutarse con privilegios (carga programas BPF y escribe en bpffs). Colócalo en un namespace con el Estándar de Seguridad de Pods privilegiado, o en kube-system, que es privilegiado por defecto.

Verificación

Desde cualquier pod en un nodo cubierto:

Salida esperada:

Cualquier otro errno (p. ej. ESOCKTNOSUPPORT 94, EAFNOSUPPORT 97) significa que el hook no está activo en ese nodo — investiga antes de asumir que estás cubierto.

Compilación

make image actualiza charts/copy-fail-blocker/values.yaml con el digest de imagen resuelto para que el chart siempre fije por digest.

Las dependencias de compilación viven en el Containerfile (clang, libbpf-dev, Go). El host local solo necesita docker buildx, helm, yq (mikefarah), kubectl y helm-diff.

Configuración

charts/copy-fail-blocker/values.yaml:

Limitaciones

• El hook solo vive mientras el pod se ejecuta. En el reinicio del pod hay una ventana corta (segundos) donde AF_ALG y AF_RXRPC de espacio de usuario vuelven a ser accesibles. Para la mayoría de los modelos de amenaza esto es aceptable; si no, considera fijar el enlace BPF a bpffs (no implementado actualmente — se aceptan contribuciones).
• Cualquiera con CAP_BPF y CAP_SYS_ADMIN en el host puede desadjuntar el hook. Esto no sustituye las restricciones de privilegios en todo el clúster.
• No bloquea algif_skcipher / algif_hash / etc. El programa rechaza toda la familia AF_ALG, pero solo se sabe que algif_aead es explotable actualmente. Si un CVE futuro necesita un filtro más fino (p. ej. hookear bind() e inspeccionar salg_type), esto es sencillo de añadir.
• Sin efecto en procesos que ya tienen un socket AF_ALG o AF_RXRPC abierto. Los sockets existentes siguen funcionando hasta que se cierran.
• No cubre la variante ESP de Dirty Frag. Esa ruta se alcanza a través de netlink XFRM y UDP_ENCAP_ESPINUDP, no mediante una familia de sockets dedicada — no se rastrea actualmente, se aceptan contribuciones. Consulta la nota en Por qué.
• Los clientes AF_RXRPC de espacio de usuario quedan bloqueados. RxRPC es el protocolo de red de AFS. La protección !kern significa que el módulo fs/afs (kAFS) del árbol sigue funcionando ya que abre sus sockets mediante sock_create_kern(). Las herramientas AFS de espacio de usuario (p. ej. daemons de espacio de usuario de OpenAFS) que abren un socket AF_RXRPC directamente mediante socket(2) serán denegadas — no despliegues este DaemonSet en nodos que ejecuten dichas herramientas.

Licencia

Apache License 2.0 — consulta LICENSE.