CVE-2026-31431 — "Copy Fail"

Escalatione dei privilegi locali nel sottosistema crittografico algif_aead del kernel Linux.

Panoramica

CVE-2026-31431, soprannominato "Copy Fail", è un bug logico nel template crittografico authencesn del kernel Linux (algif_aead). Consente a un utente locale non privilegiato di eseguire una scrittura controllata di 4 byte nella cache delle pagine di qualsiasi file leggibile, che può essere sfruttata per modificare un binario setuid e ottenere i privilegi di root.

• CVSS: 7.8 (Alto)
• Interessati: Tutti i kernel Linux mainstream distribuiti dal 2017
• Exploit: Uno script Python di 732 byte — nessuna condizione di gara, nessun offset specifico del kernel
• Fix: Commit mainline a664bf3d603d

Cronologia

Matrice di impatto

L'exploit richiede due cose: un socket AF_ALG (consentito per impostazione predefinita in tutti i profili seccomp) e un binario setuid (es. /usr/bin/su). La mitigazione chiave è allowPrivilegeEscalation: false — questo imposta il flag no_new_privs del kernel Linux tramite prctl(PR_SET_NO_NEW_PRIVS, 1), che fa sì che il kernel ignori i bit setuid/setgid su execve(). Poiché l'exploit si basa sull'esecuzione di un binario setuid modificato, questo blocca il passaggio finale di escalation.

Questa non è una funzionalità specifica di OpenShift — funziona allo stesso modo su Kubernetes vanilla (Pod Security Standards Restricted), Docker (--security-opt no-new-privileges) e Podman. OpenShift semplicemente la applica per impostazione predefinita tramite l'SCC restricted-v2, mentre altre piattaforme richiedono una configurazione esplicita.

RHEL 8 / RHEL 9

RHEL 8 e RHEL 9 includono kernel che contengono il codice vulnerabile. Un utente locale non privilegiato con accesso shell può sfruttarlo per ottenere i privilegi di root. Applicare la patch immediatamente.

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

OpenShift (4.x)

OpenShift gira su RHCOS, che include il kernel vulnerabile. L'impatto pratico dipende dai Security Context Constraints (SCC) del carico di lavoro.

I carichi di lavoro standard che utilizzano l'SCC restricted-v2 predefinito non sono sfruttabili perché allowPrivilegeEscalation: false è applicato.

I pod in esecuzione con SCC elevati (anyuid, privileged o SCC personalizzati che consentono allowPrivilegeEscalation: true) sono vulnerabili. Questo include comunemente:

• Pod di build CI/CD (agenti Jenkins, Tekton con SCC personalizzati)
• Applicazioni legacy che richiedono anyuid
• Pod di infrastruttura (monitoraggio, logging, storage)

L'accesso diretto al nodo (es. tramite oc debug node/) è sempre vulnerabile — escalation dei privilegi locale standard, nessun isolamento del container coinvolto.

Test

Viene fornito un pod di test per verificare se i prerequisiti dell'exploit sono soddisfatti nel tuo cluster. Non tenta di sfruttare la vulnerabilità — controlla solo:

1. È possibile creare un socket AF_ALG? (superficie di attacco del kernel raggiungibile)
2. no_new_privs è impostato? (blocca l'escalation setuid)
3. Sono presenti binari setuid nell'immagine del container?
4. Versione del kernel del nodo sottostante

Utilizzo (Pod)

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

Utilizzo (Deployment)

Utilizza la variante Deployment per testare su più nodi scalando le repliche o utilizzando l'anti-affinità dei pod:

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

Codici di uscita

Risultato atteso su OpenShift predefinito

Su un cluster OpenShift standard con SCC restricted-v2, dovresti vedere il codice di uscita 1 (parzialmente esposto): il socket AF_ALG può essere creato (RuntimeDefault seccomp non lo blocca), ma no_new_privs impedisce il passaggio di escalation setuid. Il PoC pubblicato non funzionerà, ma la vulnerabilità a livello di kernel è comunque raggiungibile — l'applicazione della patch è consigliata.

Mitigazione

1. Applicare la patch al kernel (P0)

Questa è l'unica soluzione completa. Aggiorna il kernel su tutti i nodi e riavvia.

Per OpenShift, aggiorna a una versione RHCOS che includa il fix ed esegui un riavvio rolling dei nodi.

2. Disabilitare il modulo algif_aead (workaround temporaneo)

Se algif_aead è compilato come modulo caricabile (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

Questo NON funziona se algif_aead è integrato (=y), che è il caso su RHCOS. Verifica con:

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

3. Bloccare AF_ALG tramite seccomp (OpenShift)

Se il modulo del kernel è integrato, l'unica mitigazione pre-patch per i container è bloccare la syscall socket(AF_ALG, ...) tramite un profilo seccomp personalizzato.

Distribuire il profilo seccomp tramite MachineConfig

Crea la MachineConfig per posizionare il profilo su tutti i nodi (ripeti con role: master per i nodi del piano di controllo):

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

Il contenuto base64 decodifica in:

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

Nota: L'applicazione di una MachineConfig attiva un riavvio rolling dei nodi.

Riferire il profilo nelle specifiche dei pod

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

Alternativa a livello di cluster

Per proteggere tutti i container senza modificare le specifiche dei pod, sovrascrivi il profilo seccomp predefinito di CRI-O (/etc/crio/seccomp.json) tramite MachineConfig aggiungendo la regola di filtro AF_ALG al profilo esistente.

4. Verificare i tuoi SCC

Identifica i pod in esecuzione con privilegi elevati:

# Trova i pod che non utilizzano 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"])"
'

Questi sono i pod in cui funziona l'intera catena dell'exploit. Dai priorità all'applicazione della patch o alla mitigazione seccomp per i nodi che eseguono questi carichi di lavoro.

Impatto della disabilitazione di AF_ALG

Il blocco dei socket AF_ALG ha un impatto trascurabile sulla maggior parte dei carichi di lavoro. I seguenti non sono interessati:

• dm-crypt / LUKS
• kTLS
• IPsec
• OpenSSL / GnuTLS (build standard)

Solo le applicazioni configurate esplicitamente per utilizzare il motore afalg di OpenSSL saranno interessate.

Riferimenti

• Copy Fail — Pagina del progetto
• Red Hat CVE-2026-31431
• NVD — CVE-2026-31431
• RuntimeDefault non blocca AF_ALG (juliet.sh)
• Xint — Analisi di Copy Fail
• The Register — Difetto nel codice crittografico Linux