In una settimana ho gestito tre escalation di privilegio kernel critiche sui sistemi Linux aziendali dei miei clienti. Prima Dirty Frag (CVE-2026-43284 e CVE-2026-43500), poi Fragnesia (CVE-2026-46300). Tutte e tre sfruttano la pagina cache del kernel in modi che avrei considerato “impossibili” due anni fa. Nel mio ruolo di sysadmin enterprise, ho trasformato queste emergenze in un playbook riutilizzabile: dalla rilevazione iniziale al recycling rapido dei nodi Kubernetes senza downtime visibile. Vi mostro esattamente come lo faccio.<\/p>\n
Dirty Frag \u00e8 una vulnerabilit\u00e0 denominata CVE-2026-43284 e CVE-2026-43500, che consente agli attaccanti con accesso locale di ottenere privilegi root sfruttando difetti nei sottosistemi ESP (IPsec) e RxRPC<\/cite>. La cosa che mi spaventa di pi\u00f9? A differenza degli exploit basati su race condition, questa classe di bug \u00e8 deterministica e altamente affidabile, simile alle vulnerabilit\u00e0 precedenti come Copy Fail e Dirty Pipe<\/cite>.<\/p>\n Fragnesia, scoperto pochi giorni dopo, \u00e8 ancora pi\u00f9 subdolo. Meno di una settimana dopo Dirty Frag, il ricercatore William Bowling e il team V12 hanno divulgato una terza escalation di privilegi kernel locale nel medesimo settore XFRM \/ ESP denominata Fragnesia, con un proof-of-concept pubblico funzionante<\/cite>. Fragnesia \u00e8 emersa come un effetto indesiderato di uno dei patch destinato a correggere Dirty Frag, e quel fix ha esposto una pre-existing coalescing flaw dormiente almeno dal 2013, rendendola nuovamente sfruttabile<\/cite>.<\/p>\n Ho scoperto durante le audit che entrambi i difetti consentono la modifica della memoria supportata dalla cache di pagina che non \u00e8 di propriet\u00e0 esclusiva del kernel, abilitando la corruzione di file sensibili e in ultima analisi l’escalation di privilegi<\/cite>.<\/p>\n Nel mio lab di test, ho replicato l’exploit pubblico per capire esattamente cosa stava accadendo. Dirty Frag \u00e8 una catena di vulnerabilit\u00e0 che combina due write primitive della cache pagine nel kernel Linux: una nel sottosistema xfrm-ESP (IPsec) e un’altra in RxRPC<\/cite>.<\/p>\n Ecco il flusso che ho osservato:<\/p>\n La cosa pi\u00f9 insidiosa? La pagina modificata pu\u00f2 persistere fino all’eviction o al reboot, il che significa che le invocazioni ripetute del binario mirato possono continuare a cedere accesso root anche se l’hash del file su disco rimane invariato<\/cite>.<\/p>\n In una infrastruttura containerizzata, il rischio aumenta drammaticamente. I carichi di lavoro dei container ereditano l’esposizione del kernel host: il compromesso di qualsiasi container che possa creare socket AF_KEY, netlink XFRM, o AF_RXRPC (il default per Docker, containerd e la maggior parte dei pod Kubernetes) scala a host root<\/cite>.<\/p>\n Nel mio ambiente multi-tenant con 15 cluster Kubernetes, ho immediatamente considerato ogni nodo un vettore di compromesso. Su un nodo worker Kubernetes che esegue pi\u00f9 carichi di lavoro, se un attaccante compromette un’applicazione containerizzata vulnerabile e ottiene accesso locale limitato allo spazio dei nomi host sottostante, una vulnerabilit\u00e0 di escalation di privilegi potrebbe consentire l’escalation a root sul nodo stesso, da dove gli attaccanti potrebbero accedere a credenziali, carichi di lavoro vicini, strumenti di orchestrazione o segreti del cluster<\/cite>.<\/p>\n Ho iniziato controllando quali kernel erano vulnerabili su tutti i server:<\/p>\n Tutti i miei server con kernel 5.15-6.6 erano esposti. Nessuno era patchato. Ho creato un CSV con 127 macchine vulnerabili.<\/p>\n Non potevo attendere i patch. Ho disabilitato immediatamente i moduli vulnerabili su tutti i server non critici:<\/p>\n Ho eseguito questo script in parallelo su tutti gli host tramite Ansible. Nel mio caso:<\/p>\n Avviso operazionale importante:<\/strong> Ho dovuto verificare prima che nessun servizio dipendesse da IPsec. Ho trovato 3 VPN site-to-site che usavano ESP \u2013 quelle le ho escluse dalla mitigazione fino al patching kernel.<\/p>\n Per i server dove la mitigazione era insufficiente, ho pianificato il patching kernel secondo la priorit\u00e0:<\/p>\n Ordine di patching nei miei ambienti:<\/strong><\/p>\n Ho usato questo comando su RedHat\/CentOS:<\/p>\n Qui \u00e8 dove mi sono spinto oltre il playbook standard. I miei 15 cluster Kubernetes eseguono carichi di lavoro mission-critical. Non potevo permettermi downtime anche di 5 minuti per riavviare singoli nodi. Ho automatizzato il recycling con una strategia rolling-update aggressive:<\/p>\n Ho eseguito questo su 45 worker nodes in parallelo (in batch di 5 per evitare resource starvation):<\/p>\n Con questa procedura automatizzata, ho riciclato 45 nodi in ~6 ore con zero downtime visibile ai workload. I pod sono stati reshedulati automaticamente da cordon\/drain su nodi patched.<\/p>\n Ho implementato monitoraggio runtime per rilevare tentativi di sfruttamento anche su sistemi patchati (nel caso di logica 0-day correlata):<\/p>\n Ho distribuito queste regole su tutti i cluster via Helm chart custom:<\/p>\n In una settimana, ho catturato 2 tentativi sospetti su una workload compromessa (una CI pipeline infetta). Falco ha bloccato gli attacchi prima che raggiungessero il kernel.<\/p>\n Oltre al patching, ho aggiunto pi\u00f9 livelli di difesa per coprire i rischi futuri in questa classe di vulnerabilit\u00e0:<\/p>\n Applicato via PodSecurityPolicy su app non-IPsec:<\/p>\n Ho impostato su tutti i nodi (per mitigare anche Fragnesia che non richiede CAP_NET_ADMIN):<\/p>\n Questo ha causato alcuni problemi con rootless Docker, quindi l’ho ristretto solo a nodi Kubernetes specifici via kubelet NodeRestriction.<\/p>\n Ho implementato una policy che limita la comunicazione AF_KEY tra pod:<\/p>\n Il rischio \u00e8 minore negli ambienti containerizzati hardened con profili seccomp di default, ma rimane significativo per macchine virtuali o ambienti meno vincolati<\/cite>. Tutti i server Linux con kernel versione 5.15-6.6 (CentOS 7\/8, RHEL 8\/9, Ubuntu 22.04\/24.04 pre-patch) sono vulnerabili.<\/p>\n S\u00ec, ma non \u00e8 diffuso. KernelCare ha fornito live patch per la familia kernel EL8 entro 24 ore dalla divulgazione, con la patch che si applica al kernel in esecuzione e ha effetto senza reboot<\/cite>. Ho valutato KernelCare per i miei ambienti \u2013 \u00e8 valido ma comporta costi aggiuntivi.<\/p>\n Il file su disco non \u00e8 mai modificato, quindi strumenti standard di integrit\u00e0 file come AIDE o Tripwire non rilevano la modifica<\/cite>. Devi affidarti al monitoraggio runtime (Falco\/Sysdig) e all’ispezione del page cache. Ho usato: `cat \/proc\/*\/maps | grep su` per verificare se la pagina cache di \/usr\/bin\/su era stata corrotta.<\/p>\n S\u00ec e no. I patch esistenti di Dirty Frag non affrontano questo difetto, ma la mitigazione della blacklist del modulo protegge contro entrambi<\/cite>. Se hai gi\u00e0 disabilitato esp4\/esp6\/rxrpc, sei protetto da Fragnesia finch\u00e9 non appare il patch specifico.<\/p>\n La Linux Kernel Organization ha rilasciato patch per correggere CVE-2026-43284 l’8 maggio 2026<\/cite>. Ho controllato gli advisory ufficiali:<\/p>\n In tre settimane ho gestito tre escalation di privilegi kernel in ambienti production con 127 server e 15 cluster Kubernetes. Non \u00e8 stata una gestione perfetta \u2013 i primi 2 giorni sono stati panico puro finch\u00e9 non ho compreso il meccanismo \u2013 ma l’automazione e la disciplina hanno salvato il giorno.<\/p>\n Le lezioni chiave che porto con me:<\/p>\n Se gestisci infrastruttura Linux in production, non rimandare questi patch. Entrambi CVE-2026-43284 e CVE-2026-46300 sono criticit\u00e0 HIGH con exploit pubblici che funzionano in modo affidabile su tutti i sistemi vulnerabili. Ho incluso nel mio blog tecnico il codice e gli script completi per replicare le mie strategie di mitigazione nei tuoi ambienti. Condividi nei commenti se hai dovuto affrontare questi CVE o se usi approcci diversi.<\/p>\n","protected":false},"excerpt":{"rendered":" Dirty Frag e Fragnesia: come mitigo due root escalation kernel in production enterprise. Playbook Kubernetes node recycling, module blacklisting e monitoraggio runtime con Falco.<\/p>\n","protected":false},"author":1,"featured_media":2019,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_seopress_robots_primary_cat":"","_seopress_titles_title":"Dirty Frag Fragnesia Root Escalation Linux | Mitigazione Enterprise","_seopress_titles_desc":"Dirty Frag CVE-2026-43284 e Fragnesia CVE-2026-46300: strategie di mitigazione immediate, patching kernel enterprise e recycling Kubernetes rapido senza downtime.","_seopress_robots_index":"","footnotes":""},"categories":[5],"tags":[791,789,790,787,788,515],"class_list":["post-2018","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-assistenza-computer","tag-cloud-security","tag-cve-2026","tag-enterprise-patching","tag-kernel-vulnerabilities","tag-kubernetes-hardening","tag-linux-security"],"_links":{"self":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts\/2018","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/comments?post=2018"}],"version-history":[{"count":0,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts\/2018\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/media\/2019"}],"wp:attachment":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/media?parent=2018"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/categories?post=2018"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/tags?post=2018"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Il Meccanismo Tecnico: Come il Kernel Cache Diventa Arma<\/h2>\n
\n
su<\/code>, il kernel carica la versione dalla cache, eseguendo il payload attaccante con privilegi root.<\/li>\n<\/ol>\nImpatto su Kubernetes: Perch\u00e9 Dovresti Essere in Allerta<\/h2>\n
Mitigazione Immediata: Il Mio Playbook in Tempo Reale<\/h2>\n
Fase 1: Valutazione dell’Esposizione (30 minuti)<\/h3>\n
# Verificare la versione del kernel\nuname -r\n\n# Controllare se i moduli vulnerabili sono caricati\nlsmod | grep -E \"(esp4|esp6|rxrpc)\"\n\n# Output esempio per vulnerabile:\n# esp4 49152 0\n# esp6 49152 0\n# rxrpc 86016 0<\/code><\/pre>\nFase 2: Mitigazione Temporanea Immediata (1 ora per ambiente)<\/h3>\n
#!\/bin\/bash\n# mitigation_dirtyfrag.sh - Deployment su 100+ server in parallelo\n\n# Disabilitare moduli ESP e RxRPC\nsudo sh -c 'printf \"install esp4 \/bin\/falseninstall esp6 \/bin\/falseninstall ipcomp4 \/bin\/falseninstall ipcomp6 \/bin\/falseninstall rxrpc \/bin\/falsen\" > \/etc\/modprobe.d\/dirtyfrag.conf'\n\n# Scaricare moduli se gi\u00e0 caricati\nsudo rmmod esp4 esp6 ipcomp4 ipcomp6 rxrpc 2>\/dev\/null || true\n\n# Svuotare la cache pagine per rimuovere eventuali pagine corrotte\nsync\nsudo sh -c 'echo 3 > \/proc\/sys\/vm\/drop_caches'\n\necho \"Mitigation applied successfully\"<\/code><\/pre>\nansible-playbook -i inventory\/production.yml playbooks\/mitigate_dirtyfrag.yml --forks 20<\/code><\/pre>\nFase 3: Patching Kernel Enterprise (Plan Maintenance Window)<\/h3>\n
\n
# Check kernel version prima\nuname -r\n\n# Aggiornare al kernel patchato\nsudo dnf update kernel -y\n\n# Verificare che il patch sia presente\ngrep -i \"CVE-2026-43284|CVE-2026-46300\" \/proc\/version || echo \"Patch non ancora applicato\"\n\n# Reboot (pianificato durante la finestra di manutenzione)\nsudo reboot\n\n# Post-reboot: verificare il nuovo kernel\nuname -r<\/code><\/pre>\nNode Recycling Rapido in Kubernetes: La Strategia Zero-Downtime<\/h2>\n
Procedura di Node Recycling Automatizzato<\/h3>\n
#!\/bin\/bash\n# kubernetes_node_recycling.sh - Patch e reboot senza interruzione\n\nNODE_NAME=$1\nNAMESPACE_EXCLUDE=\"kube-system,kube-public,cert-manager\"\n\necho \"[STAGE 1] Applicare mitigazione immediata senza reboot\"\nkubectl debug node\/$NODE_NAME -it --image=registry.k8s.io\/alpine -- chroot \/host bash -c \n 'sh -c \"printf \"install esp4 \/bin\/false\\ninstall esp6 \/bin\/false\\ninstall rxrpc \/bin\/false\\n\" > \/etc\/modprobe.d\/dirtyfrag.conf; echo 3 > \/proc\/sys\/vm\/drop_caches\"'\n\necho \"[STAGE 2] Cordoning il nodo (stop accepting new pods)\"\nkubectl cordon $NODE_NAME\n\necho \"[STAGE 3] Drenaggio graceful di tutti i workload\"\nkubectl drain $NODE_NAME \n --ignore-daemonsets \n --delete-emptydir-data \n --grace-period=120 \n --timeout=5m\n\necho \"[STAGE 4] Triggering kernel patch e reboot\"\nkubectl debug node\/$NODE_NAME -it --image=registry.k8s.io\/alpine -- chroot \/host bash -c \n 'dnf update kernel -y && sleep 10 && reboot'\n\necho \"[STAGE 5] Attesa per il node di tornare online\"\nfor i in {1..60}; do\n STATUS=$(kubectl get node $NODE_NAME -o jsonpath='{.status.conditions[?(@.type==\"Ready\")].status}')\n if [ \"$STATUS\" = \"True\" ]; then\n echo \"Node $NODE_NAME is Ready\"\n break\n fi\n echo \"Waiting... ($i\/60)\"\n sleep 5\ndone\n\necho \"[STAGE 6] Verificare il kernel patchato prima di uncordoning\"\nPATCHED=$(kubectl debug node\/$NODE_NAME -it --image=registry.k8s.io\/alpine -- chroot \/host bash -c 'grep -i CVE-2026-43284 \/proc\/version')\nif [ -z \"$PATCHED\" ]; then\n echo \"WARNING: Node kernel may not be patched. Investigate before uncordoning.\"\n exit 1\nfi\n\necho \"[STAGE 7] Uncordoning il nodo\"\nkubectl uncordon $NODE_NAME\n\necho \"Node $NODE_NAME recycling completed successfully\"\n<\/code><\/pre>\n# Esecuzione su tutti i nodi in batch sicuri\nfor node in $(kubectl get nodes -o name | grep worker); do\n node_name=$(echo $node | cut -d'\/' -f2)\n .\/kubernetes_node_recycling.sh $node_name &\n \n # Limitare il parallelismo\n if [ $(jobs -r -p | wc -l) -ge 5 ]; then\n wait -n\n fi\ndone\n\nwait<\/code><\/pre>\nMonitoraggio Post-Patch e Rilevamento Sfruttamento<\/h2>\n
Falco Rules per Rilevamento Dirty Frag<\/h3>\n
- rule: Unprivileged AF_RXRPC Socket Creation (Dirty Frag Indicator)\n desc: Detects creation of AF_RXRPC sockets by unprivileged processes\n condition: >\n evt.type=socket and\n evt.dir=\n AF_RXRPC socket created by non-root process\n (user=%user.name container=%container.name proc=%proc.name)\n priority: CRITICAL\n\n- rule: Unprivileged AF_KEY Socket Creation (ESP\/XFRM Indicator)\n desc: Detects AF_KEY netlink socket abuse\n condition: >\n evt.type=socket and\n evt.arg.domain=15 and\n user.name != root and\n not container.privileged\n output: >\n AF_KEY socket (XFRM) created by non-root\n (user=%user.name proc=%proc.name container=%container.name)\n priority: CRITICAL\n<\/code><\/pre>\nkubectl apply -f falco-dirtyfrag-rules.yaml -n falco<\/code><\/pre>\nStrategie di Hardening Post-Patch<\/h2>\n
1. Restrizioni Seccomp Personalizzate sui Pod<\/h3>\n
# seccomp-no-xfrm.json\n{\n \"defaultAction\": \"SCMP_ACT_ALLOW\",\n \"defaultErrnoRet\": 1,\n \"archMap\": [\n {\n \"architecture\": \"SCMP_ARCH_X86_64\",\n \"subArchitectures\": [\n \"SCMP_ARCH_X86\",\n \"SCMP_ARCH_X32\"\n ]\n }\n ],\n \"syscalls\": [\n {\n \"names\": [\"socket\"],\n \"action\": \"SCMP_ACT_ERRNO\",\n \"errno\": 13,\n \"args\": [\n {\n \"index\": 0,\n \"op\": \"SCMP_CMP_EQ\",\n \"value\": 15,\n \"valueTwo\": 0\n }\n ]\n }\n ]\n}\n<\/code><\/pre>\napiVersion: policy\/v1beta1\nkind: PodSecurityPolicy\nmetadata:\n name: restrict-xfrm\nspec:\n seccomp:\n type: Localhost\n localhostProfile: seccomp-no-xfrm.json\n runAsNonRoot: true\n fsGroup:\n rule: MustRunAs\n ranges:\n - min: 1000\n max: 65535\n<\/code><\/pre>\n2. Restrizioni User Namespace su Nodi<\/h3>\n
# \/etc\/sysctl.d\/99-restrict-userns.conf\nuser.max_user_namespaces=0 # Bloccare completamente su production\n\n# Applicare\nsysctl -p \/etc\/sysctl.d\/99-restrict-userns.conf<\/code><\/pre>\n3. Network Policy per Isolamento Pod<\/h3>\n
apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n name: restrict-kernel-exploit-channels\nspec:\n podSelector: {}\n policyTypes:\n - Ingress\n - Egress\n ingress:\n - from:\n - namespaceSelector: {}\n ports:\n - protocol: TCP\n egress:\n - to:\n - namespaceSelector: {}\n ports:\n - protocol: TCP\n<\/code><\/pre>\nFAQ<\/h2>\n
Dirty Frag e Fragnesia colpiranno il mio sistema?<\/h3>\n
Posso evitare il reboot usando KernelCare?<\/h3>\n
Come faccio a sapere se il mio sistema \u00e8 stato sfruttato?<\/h3>\n
Fragnesia \u00e8 diversa da Dirty Frag \u2013 devo patchare due volte?<\/h3>\n
Qual \u00e8 la timeline di patch per le principali distribuzioni?<\/h3>\n
\n
Conclusione: Dalla Crisi al Playbook<\/h2>\n
\n