A vulnerabilidade CVE-2026-31431 afeta o subsistema criptográfico do núcleo Linux e permite que um usuário local sem privilégio modifique bytes controlados no cache de páginas de arquivos legíveis.
| Componente | Núcleo Linux, no subsistema criptográfico, especificamente no módulo algif_aead usado com operações AEAD sobre soquetes AF_ALG. |
| Vetor | Usuário local sem privilégio aciona uma falha lógica que permite inserir quatro bytes controlados no cache de páginas de qualquer arquivo legível, sem exploração remota isolada. |
| Impacto | Elevação local de privilégio para root por corrupção do cache de páginas de um binário setuid, com impacto também entre contêineres por causa do compartilhamento do cache de páginas no sistema. |
| Prioridade | Aplicar os avisos e correções dos fornecedores da distribuição Linux usada, priorizando servidores multiusuário, hosts com contêineres e ambientes que aceitam contas locais de baixo privilégio. |
| Versões | A falha foi associada a uma alteração de código introduzida em agosto de 2017 e foi descrita como aplicável a distribuições Linux entregues desde 2017, incluindo Amazon Linux, RHEL, SUSE e Ubuntu. |
| Artefatos | CVE-2026-31431, codinome Copy Fail, algif_aead, AF_ALG, splice(), /usr/bin/su, binário setuid, cache de páginas e execve("/usr/bin/su"). |
A vulnerabilidade Copy Fail, rastreada como CVE-2026-31431 e classificada com pontuação CVSS 7.8, é uma falha de elevação local de privilégio no núcleo Linux. O problema permite que um processo local sem privilégio escreva quatro bytes controlados no cache de páginas de qualquer arquivo legível pelo sistema. A consequência prática descrita é a obtenção de privilégio root quando essa primitiva é aplicada contra um binário setuid, como no fluxo exemplificado com /usr/bin/su. A exploração não é remota de forma isolada: o atacante precisa executar código localmente no host, ainda que com uma conta de baixo privilégio.
O componente afetado fica no subsistema criptográfico do núcleo Linux, no módulo algif_aead. A falha decorre de uma lógica de otimização introduzida em uma alteração de código de agosto de 2017. Essa otimização permite que uma página pertencente ao cache de páginas seja posicionada como destino gravável em uma lista de dispersão usada por uma operação AEAD submetida por meio de um soquete AF_ALG. Com isso, um processo sem privilégio consegue conduzir uma operação com splice() para o soquete e completar uma escrita pequena e direcionada no cache de páginas de um arquivo que ele não possui.
O impacto é relevante porque a primitiva descrita não depende de condição de corrida nem de deslocamento específico do núcleo. A mesma classe de comportamento foi comparada à falha Dirty Pipe, CVE-2022-0847, por permitir inserção de dados no cache de páginas de arquivos somente leitura, embora o subsistema envolvido seja diferente. No caso de Copy Fail, o contexto técnico aponta que um script Python de 732 bytes seria suficiente para alterar um binário setuid e obter root em distribuições Linux amplamente usadas desde 2017, incluindo Amazon Linux, RHEL, SUSE e Ubuntu.
O fluxo de exploração começa com uma precondição local: o atacante já possui capacidade de executar um processo sem privilégio no sistema Linux. A partir desse ponto, a falha no algif_aead permite que uma operação criptográfica AEAD use indevidamente uma página do cache como destino gravável. Em vez de alterar diretamente o arquivo em disco, a operação modifica a cópia mantida no cache de páginas. Esse detalhe é central para entender o risco: o arquivo pode ser legível e não pertencer ao usuário, mas a página cacheada passa a receber quatro bytes escolhidos pelo processo atacante.
A primitiva é pequena, mas suficiente para produzir uma alteração de controle quando aplicada a um binário setuid. O contexto cita o uso de /usr/bin/su como alvo: a escrita é direcionada à cópia cacheada do binário e, em seguida, execve("/usr/bin/su") é chamado para carregar o conteúdo modificado e executar o fluxo com privilégio elevado. A menção a shellcode indica que a exploração não se limita a causar falha ou travamento; o objetivo técnico demonstrado é transformar uma escrita controlada de poucos bytes em execução privilegiada por meio de um binário carregado com atributo setuid.
A ausência de corrida e de dependência de offset do núcleo reduz a variabilidade operacional da exploração. Falhas locais de privilégio muitas vezes exigem sincronização precisa, conhecimento de layout do kernel ou adaptações por versão; neste caso, o comportamento descrito foi apresentado como portátil entre distribuições. Ainda assim, a fronteira permanece local: Copy Fail não estabelece acesso inicial pela rede por si só. O risco aumenta quando o ambiente já expõe contas locais, shells restritos, workloads de terceiros, tarefas CI/CD, contêineres ou serviços que executam código com identidades não privilegiadas no mesmo host.
A superfície exposta inclui sistemas Linux que incorporam a alteração introduzida em agosto de 2017 no caminho do algif_aead. O contexto associa a falha a distribuições entregues desde 2017 e cita Amazon Linux, RHEL, SUSE e Ubuntu. Como a vulnerabilidade está no núcleo, a análise defensiva não deve se limitar ao nome da distribuição: o ponto decisivo é a presença do código vulnerável no kernel em execução e a disponibilidade dos mecanismos necessários para acionar operações AEAD via AF_ALG com o comportamento de cache descrito.
Servidores multiusuário, estáções compartilhadas, hosts de build, nós de contêiner e máquinas que hospedam cargas de trabalho de diferentes níveis de confiança exigem prioridade maior. O impacto entre contêineres é especialmente sensível porque o cache de páginas é compartilhado por todos os processos no sistema. Assim, uma separação baseada apenas em contêiner não elimina o risco se um processo confinado conseguir acionar a primitiva contra páginas cacheadas relevantes no host. O contexto também indica capacidade de contornar sandboxing, o que reforça a necessidade de tratar a correção no nível do núcleo, e não apenas no nível da aplicação.
O principal ativo técnico citado é o binário setuid, com /usr/bin/su como exemplo concreto. A exposição, porém, não deve ser interpretada como restrita a esse caminho específico; o requisito destacado é a existência de arquivo legível cuja página cacheada possa ser corrompida e cujo uso posterior gere consequência privilegiada. Como não há indicação de exploração remota isolada, serviços de rede só entram no escopo quando fornecem execução local prévia, como shells, agentes, jobs, extensões, runners, scripts administrativos ou aplicações que permitam execução de código por usuários não privilegiados.
- Núcleos Linux contendo o comportamento vulnerável no módulo
algif_aeadintroduzido por alteração de agosto de 2017. - Distribuições citadas no contexto como afetadas em versões entregues desde 2017: Amazon Linux, RHEL, SUSE e Ubuntu.
- Hosts com binários
setuid, como/usr/bin/su, que possam ser carregados após corrupção da cópia no cache de páginas. - Ambientes com contêineres ou sandboxing em que processos de baixa confiança compartilham o mesmo cache de páginas do host.
A caça deve partir do fato de que a exploração é local e pequena. Não há domínio, endereço IP, hash de malware ou família de ameaça no contexto, portanto a detecção deve se concentrar em comportamento do endpoint e do kernel. Operadores devem procurar execuções incomuns de binários setuid, especialmente /usr/bin/su, realizadas por usuários, serviços ou contêineres que normalmente não invocam esse caminho. A sequência relevante combina atividade de processo não privilegiado, uso de interfaces criptográficas do kernel, operação com splice() e execução subsequente de um binário que concede privilégio.
Em servidores com auditoria de processos, vale correlacionar chamadas de execve para /usr/bin/su com processos ancestrais inesperados, scripts Python recentes, shells restritos, workloads de CI/CD, tarefas temporárias e processos originados de contêineres. A referência a um exploit Python de 732 bytes não deve ser tratada como assinatura suficiente, mas como indicador de que a cadeia pode ter baixo volume de código e pouca presença em disco. A telemetria deve privilegiar sequência e contexto: quem executou, de qual diretório, com qual usuário efetivo, dentro ou fora de contêiner, e com quais eventos de escalada logo depois.
Como a escrita ocorre no cache de páginas, a investigação não deve depender apenas de alterações persistentes no arquivo em disco. A cópia cacheada pode ser o ponto de modificação observado no momento da execução, enquanto a integridade estática do binário pode não refletir toda a atividade. Em incidentes suspeitos, a linha do tempo deve incluir carregamentos de binários setuid, criação ou execução de scripts curtos, uso anômalo de soquetes AF_ALG, transições de usuário para root e eventos de contêiner que precedam a escalada. A ausência de uma condição de corrida descrita significa que tentativas podem ser menos ruidosas do que explorações que precisam repetir milhares de vezes.
- Execução incomum de
/usr/bin/supor usuários, serviços, scripts ou processos de contêiner sem histórico desse comportamento. - Processos Python curtos ou temporários executados antes de uma transição de privilégio para
root. - Uso anômalo de
AF_ALG,algif_aeade operações relacionadas asplice()por processos sem privilégio. - Eventos de
execve("/usr/bin/su")correlacionados com alteração de identidade, sessão administrativa ou execução privilegiada logo em seguida. - Atividade em hosts multiusuário ou nós de contêiner em que a conta de origem não deveria ter caminho operacional para privilégio administrativo.
A resposta principal é aplicar as correções publicadas pelos fornecedores das distribuições Linux usadas no ambiente. Como a falha está no núcleo, a mitigação efetiva depende de atualizar o kernel vulnerável e reiniciar para carregar a versão corrigida quando exigido pelo ciclo de atualização da distribuição. A priorização deve começar por sistemas que aceitam execução local por usuários não confiáveis, servidores com múltiplas contas, nós de contêiner, ambientes de build e hosts em que processos de terceiros possam executar código sem privilégio.
Antes da correção completa, equipes devem reduzir a exposição operacional. Isso inclui revisar onde contas locais são necessárias, limitar execução de scripts por usuários de baixo privilégio, restringir workloads não confiáveis em hosts compartilhados e aumentar a observabilidade sobre binários setuid. Em ambientes de contêiner, a mitigação não deve assumir que a fronteira do contêiner neutraliza o problema, pois o contexto descreve impacto entre contêineres pelo compartilhamento do cache de páginas. A contenção precisa considerar o host como unidade de risco.
Depois da atualização, a validação deve confirmar a versão do kernel realmente em execução, e não apenas o pacote instalado. Também é necessário revisar eventos históricos próximos à janela de exposição, procurando escaladas locais inesperadas, execuções de /usr/bin/su, scripts Python de origem desconhecida e mudanças administrativas feitas por contas que não deveriam operar como root. Como o contexto não fornece indicadores de rede ou malware, a investigação deve evitar conclusões além do comportamento local observado. O objetivo é comprovar se houve tentativa de uso da primitiva Copy Fail, se houve obtenção de privilégio e se ações privilegiadas posteriores ocorreram no host.
- Aplicar os avisos e pacotes corrigidos da distribuição Linux e garantir que o kernel corrigido esteja carregado após reinicialização, quando necessário.
- Priorizar servidores multiusuário, hosts de contêiner, runners de CI/CD e sistemas em que usuários sem privilégio executam código local.
- Monitorar e investigar execuções anômalas de
/usr/bin/su, transições pararoote processos Python executados antes da elevação. - Revisar o uso de binários
setuide a necessidade de contas locais de baixo privilégio em sistemas compartilhados. - Tratar contêineres no mesmo host como parte da superfície de risco até que a correção do núcleo seja aplicada.
0 Comentários