Testado no Talos Linux (que acompanha CONFIG_BPF_LSM=y e bpf na pilha LSM padrão desde a v1.10), funciona em qualquer distribuição com a mesma configuração de kernel.

Porquê

Copy Fail (CVE-2026-31431) é uma falha lógica em algif_aead que permite a um usuário local sem privilégios realizar uma escrita de 4 bytes no page-cache de qualquer binário setuid, alcançando root com um script Python de 732 bytes. O exploit precisa apenas de AF_ALG + splice(), ambos alcançáveis a partir de qualquer processo sem privilégios por padrão. A correção no mainline é a664bf3d603d.

Dirty Frag é uma classe de vulnerabilidades subsequente, divulgada em maio de 2026 pela mesma linha de pesquisa. Ela encadeia dois bugs que "sujam" o membro frag de sk_buff — xfrm-ESP Page-Cache Write e RxRPC Page-Cache Write. A variante RxRPC realiza uma descriptografia in-place pcbc(fcrypt) em uma página do page-cache fixada por splice() dentro de rxkad_verify_packet_1() e alcança root sem precisar da criação de user namespaces, o que a torna a metade da cadeia mais universalmente explorável em distribuições endurecidas. A correção do xfrm-ESP chegou ao netdev como f4c50a4034e6 (2026-05-07); as distribuições ainda estão fazendo backport no momento da escrita, e o RxRPC não tem correção pública ainda — veja o relatório upstream para a linha do tempo da divulgação.

Ambos os exploits dependem da abertura de um socket na família afetada. Até que as correções do kernel cheguem à sua distribuição, a superfície de ataque pode ser removida impedindo que o espaço do usuário crie sockets AF_ALG ou AF_RXRPC. Comparado às alternativas:

Este projeto é a opção sem reinício. Execute-o em todo o cluster e depois planeje as correções permanentes do kernel no seu ritmo normal de patches.

Nota sobre a variante ESP do Dirty Frag. A metade xfrm-ESP Page-Cache Write do Dirty Frag não é fechada por este DaemonSet — ela é acionada via netlink XFRM + UDP_ENCAP_ESPINUDP, não através de uma família de sockets dedicada, e um filtro BPF-LSM limpo para ela quebraria o IPsec legítimo no host ou exigiria lógica ciente de user namespaces. Não é rastreada atualmente aqui — contribuições são bem-vindas. Em distribuições endurecidas que bloqueiam user namespaces sem privilégios (ex.: a política AppArmor padrão do Ubuntu), a variante ESP é inalcançável em primeiro lugar e o bloqueio RxRPC aqui é suficiente.

Como funciona

bpf/blocker.c é um programa BPF-LSM curto:

O carregador Go (main.go, ~40 linhas) carrega o programa e o anexa via bpf(BPF_LINK_CREATE). O link é mantido durante toda a vida do pod. No SIGTERM, o link é fechado e o hook é desanexado.

Requer um kernel compilado com CONFIG_BPF_LSM=y e bpf na pilha LSM ativa (lsm=...,bpf na linha de comando do kernel). O Talos Linux acompanha ambos habilitados por padrão desde a v1.10.

Instalação

kubectl

Para o commit mais recente em main (pode incluir mudanças não lançadas):

Helm

O chart não é publicado como artefato OCI (o caminho do registry é compartilhado com a imagem do contêiner). Instale a partir de um checkout com tag:

Ou através dos atalhos do Makefile:

O DaemonSet deve ser executado com privilégios (ele carrega programas BPF e escreve em bpffs). Coloque-o em um namespace com o Padrão de Segurança de Pod privilegiado, ou em kube-system, que é privilegiado por padrão.

Verificação

De qualquer pod em um nó coberto:

Saída esperada:

Qualquer outro errno (ex.: ESOCKTNOSUPPORT 94, EAFNOSUPPORT 97) significa que o hook não está ativo naquele nó — investigue antes de assumir que você está coberto.

Compilação

make image atualiza charts/copy-fail-blocker/values.yaml com o digest da imagem resolvido, para que o chart sempre fixe por digest.

As dependências de compilação estão no Containerfile (clang, libbpf-dev, Go). O host local precisa apenas de docker buildx, helm, yq (mikefarah), kubectl e helm-diff.

Configuração

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

Limitações

• O hook vive apenas enquanto o pod está em execução. Na reinicialização do pod há uma janela curta (segundos) em que AF_ALG e AF_RXRPC do espaço do usuário ficam alcançáveis novamente. Para a maioria dos modelos de ameaça isso é aceitável; se não for, considere fixar o link BPF em bpffs (não implementado atualmente — contribuições são bem-vindas).
• Qualquer pessoa com CAP_BPF e CAP_SYS_ADMIN no host pode desanexar o hook. Isso não substitui restrições de privilégio em todo o cluster.
• Não bloqueia algif_skcipher / algif_hash / etc. O programa rejeita toda a família AF_ALG, mas apenas algif_aead é atualmente conhecido por ser explorável. Se um CVE futuro precisar de um filtro mais fino (ex.: hook bind() e inspecionar salg_type), isso é simples de adicionar.
• Nenhum efeito em processos que já possuem um socket AF_ALG ou AF_RXRPC aberto. Sockets existentes continuam funcionando até serem fechados.
• Não cobre a variante ESP do Dirty Frag. Esse caminho é alcançado através do netlink XFRM e UDP_ENCAP_ESPINUDP, não através de uma família de sockets dedicada — não é rastreado atualmente, contribuições são bem-vindas. Veja a nota em Porquê.
• Clientes AF_RXRPC do espaço do usuário são bloqueados. RxRPC é o protocolo de rede AFS. A proteção !kern significa que o módulo fs/afs (kAFS) no kernel continua funcionando, pois ele abre seus sockets via sock_create_kern(). Ferramentas AFS do espaço do usuário (ex.: daemons OpenAFS do espaço do usuário) que abrem um socket AF_RXRPC diretamente via socket(2) serão negadas — não implante este DaemonSet em nós que executam tais ferramentas.

Licença

Apache License 2.0 — veja LICENSE.