GhostLock, nuova falla nel Kernel Linux e nel suo semaforo dei processi (mutex): root e fuga dai container

Un’altra vulnerabilità nel Kernel Linux, soprannominata GhostLock, permette a un utente locale senza privilegi speciali di diventare root e, come Januscape, permette di uscire verso l’host, ma stavolta da dentro un container invece che da una VM. Colpisce praticamente ogni distribuzione mainstream dal 2011 in poi, ed è ragionevole aspettarsi che l’impatto resti ampio finché non viene applicata la patch corretta, qualunque sia il ramo di Kernel in uso.

La falla, tracciata come CVE-2026-43499, è stata segnalata da Nebula Security, che l’ha trovata con VEGA, il proprio strumento di analisi automatizzata. Ancora una volta abbiamo una vulnerabilità che viene trovata e rilasciata in occasione della competizione kernelCTF di Google. Vive nel codice dei real-time mutex del kernel (rtmutex.c), sul percorso di priority inheritance, il meccanismo semaforico con cui il kernel evita che un thread a bassa priorità blocchi indefinitamente uno a priorità più alta prestandogli temporaneamente la propria priorità.

Questa volta il problema sta nella funzione remove_waiter(), che dà per scontato che il waiter da ripulire appartenga sempre al thread attualmente in esecuzione. Nel percorso FUTEX_CMP_REQUEUE_PI, però, il kernel deve a volte disfare l’operazione per conto di un thread diverso, che nel frattempo è addormentato, quando rileva un ciclo di deadlock e deve tornare indietro con un errore. Durante questo rollback, il Kernel azzera il riferimento pi_blocked_on sul thread sbagliato, lasciando un puntatore pending verso memoria dello stack già liberata: un’altra use-after-free, ma sullo stack, invece che sull’heap come nella maggior parte dei bug di questo tipo.

Un attaccante innesca il bug organizzando tre futex e un gruppo di thread coordinati in un deadlock da inversione di priorità, per poi rioccupare lo stack frame liberato con una struttura waiter contraffatta. Da lì, il write-up pubblico trasforma questa scrittura vincolata in lettura e scrittura arbitraria di memoria kernel, dirottamento del flusso di esecuzione, e infine una shell di root: parliamo di una Local Privilege Escalation che funziona anche per uscire da un container. A differenza di Januscape non stiamo parlando di una VM escape guest-to-host, ma di una vulnerabilità non di impatto per ambienti virtualizzati dato che colpisce principalmente i sistemi containerizzati.

La vulnerabilità rimane comunque molto grave perché non richiede nessuna capability e permette di diventare root in ambienti containerizzati condivisi o multi tenant dove l’isolamento del Kernel è l’unica barriera tra processi.

Una Proof of Concept funzionante di questo attacco è disponibile su GitHub. Nebusec ha anche rilasciato il seguente video di dimostrazione che mostra GhostLock che, eseguito come utente non privilegiato, consegna una shell di root a seguito dell’attacco.

Come altre falle recenti di cui abbiamo parlato, anche GhostLock è vecchissima: introdotta nel 2011 (Linux 2.6.39), è rimasta inosservata per circa 15 anni. Dipende solo da CONFIG_FUTEX_PI, un’opzione abilitata praticamente ovunque, quindi l’esposizione è enorme. È stata corretta in mainline con il commit 3bfdc63936dd, in arrivo con Linux 7.1. L’unica opzione possibile in questi casi, come sempre, è aggiornare all’ultima versione disponibile.

Tra Januscape e ora GhostLock, abbiamo capito come componenti core del Kernel Linux, alcuni vecchi di oltre un decennio, continuino a nascondere bug di concorrenza sfruttabili in modo affidabile. E ancora una volta queste CVE emergono in occasione di competizioni o programmi di bug bounty, spesso individuate da strumenti di analisi automatizzata basati su AI. La domanda che sorge spontanea è: queste vulnerabilità vengono trovate durante le CTF o competizioni simili, oppure vengono già sfruttate e rilasciate solo in occasione di un premio o per visibilità?

Non si tratta comunque di un episodio isolato di scarsa qualità del codice, ma della conferma che la ricerca di sicurezza, umana o assistita da modelli AI, sta diventando sempre più brava a stanare esattamente questo tipo di bug, specialmente legati alla memoria e nascosti per anni in codice sotto gli occhi di tutti.

Red Team & Offensive Security Engineer
Parlo di sicurezza informatica offensive, Linux e Open Source

4 risposte a “GhostLock, nuova falla nel Kernel Linux e nel suo semaforo dei processi (mutex): root e fuga dai container”

  1. Avatar mimmus
    mimmus

    Sta diventando impossibile starci dietro, sia per chi deve gestire centinaia o migliaia di macchine in ambienti enterprise sia per le distro, che mi sembrano diventate davvero lente a rilasciare le fix.
    Noi avevamo un ciclo trimestrale di patching nei vari ambienti, ora è diventato decisamente inattuale.
    Il rischio è diminuire la stabilità dell'ambiente complessivo.
    E' chiaro che parliamo di applicazioni "legacy" ma in giro ce ne sono tonnellate, la realtà spesso è lontana da apploicazioni cloud-native, container, serverless, …

  2. Avatar sabayonino
    sabayonino

    Ancora una volta abbiamo una vulnerabilità che viene trovata e rilasciata in occasione della competizione kernelCTF di Google.

    L'importante è che paghi 😀 …
    Intanto ne scoveranno altre e ci vedremo al prossimo challenge… l'importante è che paghi

    sempre se non passa qualcun'altro prima

  3. Avatar mimmus
    mimmus

    Sta diventando impossibile starci dietro, sia per chi deve gestire centinaia o migliaia di macchine in ambienti enterprise sia per le distro enterprise, che mi sembrano diventate davvero lente a rilasciare le fix

  4. Avatar michele
    michele

    forse, dove possibile, l'alternativa BSD?

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *