No subsistema de criptografia do Linux, está sendo preparado o encerramento do suporte zero-copy da interface AF_ALG para tipos de algoritmos SKCIPHER e AEAD. A alteração já está no repositório cryptodev e deve ser enviada para a janela de fusão Linux 7.2, que deve abrir em junho. O motivo foram as crescentes preocupações em torno da segurança dos mecanismos de zero-copy no núcleo, especialmente após vulnerabilidades recentes no código criptográfico do Linux.
AF_ALG seja a interface do usuário para a API de criptografia do núcleo Linux. Através dela, programas podem acessar implementações de cifras, hashes e algoritmos AEAD no núcleo como se fossem sockets. A documentação do Linux descreve separadamente para AF_ALG o modo de zero-copy por meio de splice() e vmsplice(), onde o núcleo tenta evitar cópias desnecessárias de dados na memória do núcleo.
O problema é que, no caso de AF_ALG, esse ganho de desempenho não se mostrou tão relevante, enquanto os riscos são muito altos. O autor da alteração, o desenvolvedor do subsistema criptográfico do Linux, Eric Biggers do Google, referiu, afirma que o zero-copy permite que o espaço do usuário execute operações criptográficas diretamente sobre as páginas do cache de páginas de arquivos, como o binário su, além de criar condições para vulnerabilidades TOCTOU, quando a memória pode ser alterada ao mesmo tempo que uma operação ocorre sobre ela.
Em outras palavras, um mecanismo que é útil em entrada/saída de rede ou de arquivos no AF_ALG parece uma otimização excessivamente arriscada. O próprio AF_ALG, segundo o desenvolvedor, atualmente é mantido principalmente por compatibilidade retroativa com um pequeno conjunto de programas, como o iwd, que ainda não foram convertidos para cripto no espaço do usuário. Originalmente, o AF_ALG foi pensado para acesso a aceleradores de criptografia de hardware, mas na prática se mostrou uma interface não muito eficiente para essa tarefa.
É importante ressaltar que não se trata da remoção completa de splice() ou sendfile() para AF_ALG. A alteração é descrita como uma "quebra suave" de compatibilidade: a transferência de dados em solicitações AF_ALG através de splice() e sendfile() continuará funcionando, mas agora o núcleo fará uma cópia interna estável dos dados antes da operação criptográfica. O desempenho pode diminuir em alguns casos, mas a API do usuário formalmente não é quebrada.
É destacado que, por enquanto, o zero-copy está sendo removido de skcipher e aead. O suporte para o tipo hash será considerado separadamente.
O contexto da mudança é desagradável. No final de abril, foi descoberta uma vulnerabilidade Falha de Cópia (CVE-2026-31431) no algif_aead, que é precisamente na interface de criptografia do usuário AF_ALG. Pesquisadores mostraram que a combinação de AF_ALG, splice() e características do processamento AEAD permitia que um usuário não privilegiado danificasse o cache de páginas, incluindo páginas correspondentes a binários setuid, e obtivesse elevação de privilégios para root.
A aparição Falha de Cópia estava relacionada à otimização de 2017, que transferiu as operações AEAD para processamento "in-place"; ao transferir arquivos via splice() em AF_ALG, o núcleo operava não com cópias, mas com referências às páginas do cache de páginas. Como resultado, parte dos dados que eram considerados apenas de entrada podiam acabar em um scatterlist gravável.
A remoção do zero-copy do AF_ALG não é uma correção pontual apenas para uma vulnerabilidade. Em vez disso, é uma tentativa de eliminar toda uma classe de cenários arriscados de uma UAPI pouco utilizada, onde o ganho da otimização não justifica a complexidade e as consequências potenciais. Para usuários comuns, a mudança provavelmente permanecerá imperceptível; para programas raros que utilizam ativamente o AF_ALG através de splice() ou sendfile(), pode haver uma queda de desempenho devido à cópia adicional.
Fonte: linux.org.ru
