OVSwrap: un bug di 13 anni nel kernel Linux diventa privilege…

Il 28 luglio 2026 Asim Manizada ha pubblicato su oss-security la disclosure completa di CVE-2026-64531 , battezzata OVSwrap: una vulnerabilità di corruzione memoria

{"main_topic":"cybersecurity","topics":["cybersecurity","vulnerabilita","cve","linux","exploit","privilege-escalation","open-source"]}

Punti chiave

Il ricercatore Asim Manizada ha divulgato il 28 luglio 2026 CVE-2026-64531, una vulnerabilità nel datapath kernel di Open vSwitch che consente privilege escalation locale fino a root tramite wraparound di un campo a 16 bit.
Un commit di marzo 2025 ha rimosso un cap di 32 KiB sulle azioni OVS, esponendo un bug latente esistente da tredici anni e rendendolo sfruttabile in configurazione default su decine di distribuzioni.
L'exploit PoC pubblico include record pre-costruiti per circa 800 build kernel x86-64 e non richiede Open vSwitch in esecuzione, bridge configurate o CAP_NET_ADMIN iniziale.
CloudLinux ha confermato che CageFS non blocca l'attacco: su server multi-utente, un singolo sito compromesso tramite vulnerabilità indipendente può essere elevato a root sull'intero host.

Il 28 luglio 2026 Asim Manizada ha pubblicato su oss-security la disclosure completa di CVE-2026-64531, battezzata OVSwrap: una vulnerabilità di corruzione memoria nel datapath kernel di Open vSwitch che permette a un utente locale non privilegiato di ottenere privilegi di root. Il bug esisteva da tredici anni in stato latente, ma è diventato sfruttabile solo nel marzo 2025, quando un commit di manutenzione ha rimosso un controllo di affidabilità che ne mascherava la pericolosità. L'exploit proof-of-concept è pubblico e funziona in configurazione default su decine di distribuzioni enterprise.

Come funziona il wraparound di nla_len

Il meccanismo si annida nel parsing delle azioni Netlink innestate nel datapath kernel di Open vSwitch. Il campo nla_len che misura la lunghezza degli attributi annidati è un intero senza segno a 16 bit, con limite massimo di 65.535 byte. Quando un'azione CLONE contiene centinaia di sotto-azioni conntrack, ognuna espansa a 164 byte su x86-64, la somma supera questo limite. Il valore troncato causa un wraparound: il parser riprende da un offset controllato dall'attaccante, interpretando dati forgieti come azioni OVS legittime.

Manizada ha concatenato tre primitive precise per evitare complesse tecniche di heap grooming, sfruttando la natura deterministica del buffer contiguo: un kernel pointer leak tramite fake OUTPUT, una arbitrary read tramite forged tunnel SET, e infine un targeted decrement sulle credenziali kernel tramite tun_dst teardown. La catena esegue in modo affidabile, con quello che il ricercatore definisce "logic-bug-grade reliability" secondo quanto riportato da The Hacker News.

Il commit che ha trasformato un bug in arma

Il commit a1e64addf3ff, datato marzo 2025 e intitolato "net: openvswitch: remove misbehaving actions length check", ha eliminato un cap di 32 KiB sullo stream di azioni che era stato introdotto per gestire fallimenti in ambienti OpenStack. La modifica era finalizzata a migliorare la robustezza operativa: con il cap, pacchetti complessi venivano scartati generando errori. Senza il cap, quegli stessi pacchetti attraversano il sistema e attivano il wraparound.

Questa dinamica illustra una tensione sistemica tra reliability engineering e security assessment. Ottimizzazioni di robustezza introdotte senza analisi del modello di minaccia possono esporre primitive latenti che, pur esistendo da anni, diventano armi solo quando il contesto operativo cambia. Il kernel Linux ha ricevuto il fix il 24 luglio 2026 tramite il commit 3f1f75536668 ("net: openvswitch: reject oversized nested action attrs"), ma le stable releases patchate — 5.15.212, 6.1.178, 6.6.145, 6.12.97, 6.18.40, 7.1.5 — devono ancora propagarsi nei repository delle singole distribuzioni.

La matrice di esposizione: chi è affetto

Secondo la disclosure originale e le ricostruzioni di The Hacker News, l'exploit è stato testato con successo su una gamma estesa di distribuzioni: AlmaLinux 9/10, Alpine 3.22-3.24, Amazon Linux 2023, Arch, CentOS Stream 9/10, Debian 12/13, Fedora 42-44, Gentoo, Kali 2026.1, Linux Mint 22.3, NixOS, openSUSE Tumbleweed, Pop!_OS, Rocky Linux 9/10 e Ubuntu 22.04. Ubuntu 24.04 risulta esponibile tramite fallback aa-exec; Ubuntu 26.04 è bloccata in configurazione stock ma diventa vulnerabile disabilitando apparmor_restrict_unprivileged_userns. Sistemi con kernel più datati — Amazon Linux 2, Debian 11, Rocky Linux 8, Ubuntu 20.04 — non sono affetti perché precedono il commit abilitante.

"no existing OVS bridge, no running ovs-vswitchd, no host-level CAP_NET_ADMIN"

Il PoC di Manizada non richiede Open vSwitch in esecuzione, bridge configurate né capacità iniziali di rete. I soli prerequisiti sono: modulo openvswitch presente nel sistema, supporto conntrack/FTP helper attivo, e sudo installato. Questo abbassa drasticamente la superficie di attacco: un utente non privilegiato che ottiene esecuzione di codice tramite qualsiasi vulnerabilità indipendente — un plugin outdated su un server condiviso — può elevarsi a root senza interagire con la configurazione di rete esistente.

Le contro-misure e i loro limiti

La mitigazione di emergenza documentata da CloudLinux è la blocklist del modulo tramite echo 'install openvswitch /bin/false' > /etc/modprobe.d/ovswrap.conf, che però rompe gli stack OpenStack e Kubernetes che dipendono da Open vSwitch per il networking SDN. Questo crea una tensione operativa immediata: proteggere la sicurezza o mantenere la funzionalità dei cluster.

Alcune precauzioni ritenute standard si rivelano inefficaci. Secondo il ricercatore, "An empty lsmod output does not mean a system is safe": il modulo openvswitch può auto-caricarsi tramite risoluzione del Generic Netlink family name anche se non presente in memoria. CloudLinux ha confermato che CageFS, il suo meccanismo di isolamento filesystem, "does not restrict the netlink call that triggers the module load". AppArmor e SELinux non bloccano l'exploit una volta ottenuto CAP_NET_ADMIN.

Disabilitare gli unprivileged user namespaces — misura raccomandata in diverse advisory di sicurezza kernel — interrompe il percorso di attacco ordinario ma non quello da container con CAP_NET_ADMIN, che Manizada ha descritto come teoricamente raggiungibile senza averlo dimostrato nel PoC rilasciato.

Cosa fare adesso

Per gli amministratori di sistema che gestiscono infrastrutture multi-utente o hosting condiviso, le azioni prioritarie derivano direttamente dalle fonti disponibili:

Verificare lo stato del modulo: eseguire lsmod | grep openvswitch ma considerare che l'output vuoto non garantisce protezione, dato il meccanismo di auto-caricamento via Generic Netlink.
Applicare il blocco modprobe se la funzionalità OVS non è necessaria: creare il file /etc/modprobe.d/ovswrap.conf con la direttiva di blocklist documentata da CloudLinux, con la consapevolezza che questa azione disabilita componenti di networking virtualizzato.
Pianificare l'aggiornamento kernel: le versioni patchate sono disponibili upstream; per CloudLinux 9/10 e Ubuntu 22.04 è disponibile il livepatch KernelCare dal 30 luglio 2026, che richiede licenza attiva.
Monitorare i canali vendor per AlmaLinux/RHEL: CloudLinux indica che i kernel patchati sono attesi negli stream AlmaLinux 9.9 e 10.3 o successivi, senza data fissa al momento della stesura.

Perché questo caso conta oltre il singolo CVE

OVSwrap non è una vulnerabilità isolata ma un caso di studio su come l'ingegneria della robustezza possa generare debito di sicurezza. Il commit del marzo 2025 era tecnicamente corretto: rimuoveva un comportamento che causava fallimenti legittimi in OpenStack. Ma la rimozione del cap ha spostato il confine operativo in una zona dove un bug di aritmetica intera, latente da tredici anni, diventava esercitabile.

Il rischio concreto si concentra sui server multi-utente: come ha documentato CloudLinux, "one compromised website on a shared server becomes root on the whole server", e "Local here does not mean an employee or a customer you trust. On a shared server, the local user is whoever just got into one of the sites you host through an outdated plugin". L'exploit PoC pubblico, con i suoi circa 800 record kernel pre-costruiti, rende questa escalation un evento riproducibile più che una teoria.

Non emerge alcuna conferma di exploitation in-the-wild attiva, ma la disponibilità pubblica del codice e la semplicità dei prerequisiti riducono il tempo di window di esposizione. Il brief non specifica se esistano varianti architetturali non x86-64 o se il modulo openvswitch possa essere compilato built-in in configurazioni kernel particolari, circostanze che renderebbero la mitigazione modprobe inefficace.

Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.

Fonti

Fonti e riferimenti