CVE-2026-31431 — "Copy Fail"

Escalação de Privilégio Local no subsistema criptográfico algif_aead do kernel Linux.

Visão Geral

CVE-2026-31431, apelidada de "Copy Fail", é um bug lógico no template criptográfico authencesn do kernel Linux (algif_aead). Ele permite que um usuário local sem privilégios realize uma escrita controlada de 4 bytes no cache de páginas de qualquer arquivo legível, o que pode ser explorado para modificar um binário setuid e obter acesso root.

• CVSS: 7.8 (Alto)
• Afetados: Todos os kernels Linux convencionais distribuídos desde 2017
• Exploit: Um script Python de 732 bytes — sem condições de corrida, sem offsets específicos do kernel
• Correção: Commit mainline a664bf3d603d

Linha do Tempo

Matriz de Impacto

O exploit requer duas coisas: um socket AF_ALG (permitido por padrão em todos os perfis seccomp) e um binário setuid (ex.: /usr/bin/su). A mitigação principal é allowPrivilegeEscalation: false — isso define o flag no_new_privs do kernel Linux via prctl(PR_SET_NO_NEW_PRIVS, 1), o que faz o kernel ignorar os bits setuid/setgid no execve(). Como o exploit depende da execução de um binário setuid modificado, isso bloqueia a etapa final de escalação.

Isso não é um recurso específico do OpenShift — funciona da mesma forma em Kubernetes vanilla (Padrões de Segurança de Pod Restricted), Docker (--security-opt no-new-privileges) e Podman. O OpenShift simplesmente o aplica por padrão via SCC restricted-v2, enquanto outras plataformas exigem configuração explícita.

RHEL 8 / RHEL 9

RHEL 8 e RHEL 9 incluem kernels que contêm o código vulnerável. Um usuário local sem privilégios com acesso ao shell pode explorar isso para obter root. Aplique o patch imediatamente.

yum updateinfo list cves CVE-2026-31431
yum update kernel

OpenShift (4.x)

O OpenShift roda em RHCOS, que inclui o kernel vulnerável. O impacto prático depende das Restrições de Contexto de Segurança (SCC) da carga de trabalho.

Cargas de trabalho padrão usando o SCC restricted-v2 (padrão) não são exploráveis porque allowPrivilegeEscalation: false é aplicado.

Pods executando com SCCs elevados (anyuid, privileged ou SCCs personalizados que permitem allowPrivilegeEscalation: true) são vulneráveis. Isso comumente inclui:

• Pods de build CI/CD (agentes Jenkins, Tekton com SCCs personalizados)
• Aplicações legadas que exigem anyuid
• Pods de infraestrutura (monitoramento, logging, armazenamento)

Acesso direto ao nó (ex.: via oc debug node/) é sempre vulnerável — escalação de privilégio local padrão, sem isolamento de contêiner envolvido.

Teste

Um pod de teste é fornecido para verificar se os pré-requisitos do exploit são atendidos no seu cluster. Ele não tenta explorar a vulnerabilidade — apenas verifica:

1. Um socket AF_ALG pode ser criado? (superfície de ataque do kernel alcançável)
2. no_new_privs está definido? (bloqueia escalação via setuid)
3. Binários setuid estão presentes na imagem do contêiner?
4. Versão do kernel do nó subjacente

Uso (Pod)

oc apply -f test-pod.yaml
oc logs cve-2026-31431-check
oc delete -f test-pod.yaml

Uso (Deployment)

Use a variante Deployment para testar em vários nós escalando réplicas ou usando anti-afinidade de pod:

oc apply -f test-deployment.yaml
oc logs -l app=cve-2026-31431-check
oc delete -f test-deployment.yaml

Códigos de saída

Resultado esperado no OpenShift padrão

Em um cluster OpenShift padrão com SCC restricted-v2, você deve ver o código de saída 1 (parcialmente exposto): o socket AF_ALG pode ser criado (o seccomp RuntimeDefault não o bloqueia), mas no_new_privs impede a etapa de escalação via setuid. O PoC publicado não funcionará, mas a vulnerabilidade em nível de kernel ainda é alcançável — a aplicação do patch é recomendada.

Mitigação

1. Aplique o patch no kernel (P0)

Esta é a única correção completa. Atualize o kernel em todos os nós e reinicie.

Para OpenShift, atualize para uma versão RHCOS que inclua a correção e realize um reboot rolante dos nós.

2. Desative o módulo algif_aead (solução temporária)

Se algif_aead for compilado como módulo carregável (CONFIG_CRYPTO_USER_API_AEAD=m):

echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf
rmmod algif_aead 2>/dev/null || true

Isso NÃO funciona se algif_aead estiver embutido (=y), que é o caso no RHCOS. Verifique com:

modinfo algif_aead 2>&1 | grep builtin
grep CONFIG_CRYPTO_USER_API_AEAD /boot/config-$(uname -r)

3. Bloqueie AF_ALG via seccomp (OpenShift)

Se o módulo do kernel estiver embutido, a única mitigação pré-patch para contêineres é bloquear a syscall socket(AF_ALG, ...) via um perfil seccomp personalizado.

Implante o perfil seccomp via MachineConfig

Crie o MachineConfig para colocar o perfil em todos os nós (repita com role: master para nós do plano de controle):

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: worker
  name: 99-worker-seccomp-deny-af-alg
spec:
  config:
    ignition:
      version: 3.2.0
    storage:
      files:
        - path: /var/lib/kubelet/seccomp/deny-af-alg.json
          mode: 0644
          contents:
            source: data:application/json;charset=utf-8;base64,ewogICJkZWZhdWx0QWN0aW9uIjogIlNDTVBfQUNUX0FMTE9XIiwKICAic3lzY2FsbHMiOiBbCiAgICB7CiAgICAgICJuYW1lcyI6IFsic29ja2V0Il0sCiAgICAgICJhY3Rpb24iOiAiU0NNUF9BQ1RfRVJSTk8iLAogICAgICAiYXJncyI6IFsKICAgICAgICB7CiAgICAgICAgICAiaW5kZXgiOiAwLAogICAgICAgICAgInZhbHVlIjogMzgsCiAgICAgICAgICAib3AiOiAiU0NNUF9DTVBfRVEiCiAgICAgICAgfQogICAgICBdCiAgICB9CiAgXQp9

O conteúdo base64 decodifica para:

{
  "defaultAction": "SCMP_ACT_ALLOW",
  "syscalls": [
    {
      "names": ["socket"],
      "action": "SCMP_ACT_ERRNO",
      "args": [
        {
          "index": 0,
          "value": 38,
          "op": "SCMP_CMP_EQ"
        }
      ]
    }
  ]
}

Nota: Aplicar um MachineConfig aciona um reboot rolante dos nós.

Referencie o perfil nas especificações do pod

securityContext:
  seccompProfile:
    type: Localhost
    localhostProfile: deny-af-alg.json

Alternativa em todo o cluster

Para proteger todos os contêineres sem modificar as especificações dos pods, substitua o perfil seccomp padrão do CRI-O (/etc/crio/seccomp.json) via MachineConfig adicionando a regra de filtro AF_ALG ao perfil existente.

4. Audite seus SCCs

Identifique pods executando com privilégios elevados:

# Encontre pods que não usam restricted-v2
oc get pods -A -o json | jq -r '
  .items[] |
  select(.metadata.annotations["openshift.io/scc"] != "restricted-v2") |
  "\(.metadata.namespace)/\(.metadata.name) → \(.metadata.annotations["openshift.io/scc"])"
'

Esses são os pods onde a cadeia completa do exploit funciona. Priorize o patch ou a mitigação via seccomp para nós que executam essas cargas de trabalho.

Impacto de desativar AF_ALG

Bloquear sockets AF_ALG tem impacto insignificante na maioria das cargas de trabalho. Os seguintes não são afetados:

• dm-crypt / LUKS
• kTLS
• IPsec
• OpenSSL / GnuTLS (builds padrão)

Apenas aplicações explicitamente configuradas para usar o engine afalg do OpenSSL serão afetadas.

Referências

• Copy Fail — Página do Projeto
• Red Hat CVE-2026-31431
• NVD — CVE-2026-31431
• RuntimeDefault não bloqueia AF_ALG (juliet.sh)
• Xint — Análise do Copy Fail
• The Register — Falha no código criptográfico do Linux