Testato su Talos Linux (che include CONFIG_BPF_LSM=y e bpf nello stack LSM predefinito dalla v1.10), funziona su qualsiasi distribuzione con la stessa configurazione del kernel.

Perché

Copy Fail (CVE-2026-31431) è un difetto logico in algif_aead che consente a un utente locale non privilegiato di eseguire una scrittura di 4 byte nella page cache di qualsiasi binario setuid, ottenendo root con uno script Python di 732 byte. L'exploit richiede solo AF_ALG + splice(), entrambi raggiungibili da qualsiasi processo non privilegiato per impostazione predefinita. La correzione mainline è a664bf3d603d.

Dirty Frag è una classe di vulnerabilità successiva, divulgata a maggio 2026 dalla stessa linea di ricerca. Combina due bug che "sporcano" il membro frag di sk_buff — xfrm-ESP Page-Cache Write e RxRPC Page-Cache Write. La variante RxRPC esegue una decrittazione in-place pcbc(fcrypt) su una pagina della page cache bloccata con splice() all'interno di rxkad_verify_packet_1() e raggiunge root senza bisogno di creare namespace utente, il che la rende la metà della catena più universalmente sfruttabile sulle distribuzioni indurite. La correzione per xfrm-ESP è arrivata in netdev come f4c50a4034e6 (2026-05-07); le distribuzioni stanno ancora facendo backport al momento della scrittura, e RxRPC non ha ancora una correzione pubblica — vedi il write-up upstream per la cronologia della divulgazione.

Entrambi gli exploit dipendono dall'apertura di un socket nella famiglia interessata. Finché le correzioni del kernel non arrivano nella tua distribuzione, la superficie di attacco può essere rimossa impedendo allo spazio utente di creare socket AF_ALG o AF_RXRPC. Rispetto alle alternative:

Questo progetto è l'opzione senza riavvio. Eseguilo a livello di cluster, poi pianifica le correzioni permanenti del kernel con la tua normale cadenza di patch.

Nota sulla variante ESP di Dirty Frag. La metà xfrm-ESP Page-Cache Write di Dirty Frag non viene chiusa da questo DaemonSet — viene attivata tramite netlink XFRM + UDP_ENCAP_ESPINUDP, non tramite una famiglia di socket dedicata, e un filtro BPF-LSM pulito per essa romperebbe l'IPsec legittimo sull'host o richiederebbe una logica consapevole dei namespace utente. Non attualmente tracciata qui — i contributi sono benvenuti. Sulle distribuzioni indurite che bloccano i namespace utente non privilegiati (ad es. la policy AppArmor predefinita di Ubuntu), la variante ESP è irraggiungibile in primo luogo e il blocco RxRPC qui è sufficiente.

Come funziona

bpf/blocker.c è un breve programma BPF-LSM:

Il loader Go (main.go, ~40 righe) carica il programma e lo collega tramite bpf(BPF_LINK_CREATE). Il link viene mantenuto per tutta la durata del pod. Su SIGTERM, il link viene chiuso e l'hook si scollega.

Richiede un kernel compilato con CONFIG_BPF_LSM=y e bpf nello stack LSM attivo (lsm=...,bpf sulla riga di comando del kernel). Talos Linux include entrambi abilitati per impostazione predefinita dalla v1.10.

Installazione

kubectl

Per l'ultimo commit su main (potrebbe includere modifiche non rilasciate):

Helm

Il chart non è pubblicato come artefatto OCI (il percorso del registry è condiviso con l'immagine del container). Installa da un checkout taggato:

Oppure tramite le scorciatoie del Makefile:

Il DaemonSet deve essere eseguito con privilegi (carica programmi BPF e scrive su bpffs). Posizionalo in un namespace con lo standard di sicurezza Pod Security privilegiato, oppure in kube-system, che è privilegiato per impostazione predefinita.

Verifica

Da qualsiasi pod su un nodo coperto:

Output atteso:

Qualsiasi altro errno (ad es. ESOCKTNOSUPPORT 94, EAFNOSUPPORT 97) significa che l'hook non è attivo su quel nodo — indaga prima di presumere di essere coperto.

Build

make image aggiorna charts/copy-fail-blocker/values.yaml con il digest dell'immagine risolto, così il chart fissa sempre per digest.

Le dipendenze di build vivono nel Containerfile (clang, libbpf-dev, Go). L'host locale richiede solo docker buildx, helm, yq (mikefarah), kubectl e helm-diff.

Configurazione

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

Limitazioni

• L'hook vive solo finché il pod è in esecuzione. Al riavvio del pod c'è una breve finestra (secondi) in cui AF_ALG e AF_RXRPC da spazio utente sono di nuovo raggiungibili. Per la maggior parte dei modelli di minaccia questo è accettabile; in caso contrario, considera di fissare il link BPF a bpffs (non attualmente implementato — i contributi sono benvenuti).
• Chiunque abbia CAP_BPF e CAP_SYS_ADMIN sull'host può scollegare l'hook. Questo non sostituisce le restrizioni dei privilegi a livello di cluster.
• Non blocca algif_skcipher / algif_hash / ecc. Il programma rifiuta l'intera famiglia AF_ALG, ma solo algif_aead è attualmente noto per essere sfruttabile. Se una futura CVE richiede un filtro più fine (ad es. hook su bind() e ispezione di salg_type), è semplice da aggiungere.
• Nessun effetto sui processi che hanno già un socket AF_ALG o AF_RXRPC aperto. I socket esistenti continuano a funzionare finché non vengono chiusi.
• Non copre la variante ESP di Dirty Frag. Quel percorso viene raggiunto tramite netlink XFRM e UDP_ENCAP_ESPINUDP, non tramite una famiglia di socket dedicata — non attualmente tracciato, i contributi sono benvenuti. Vedi la nota in Perché.
• I client AF_RXRPC da spazio utente sono bloccati. RxRPC è il protocollo di rete AFS. La guardia !kern significa che il modulo in-tree fs/afs (kAFS) continua a funzionare poiché apre i suoi socket tramite sock_create_kern(). Gli strumenti AFS da spazio utente (ad es. i daemon userspace OpenAFS) che aprono un socket AF_RXRPC direttamente tramite socket(2) verranno negati — non distribuire questo DaemonSet su nodi che eseguono tali strumenti.

Licenza

Apache License 2.0 — vedi LICENSE.