Una vulnerabilità è stata scoperta nel kernel Linux CVE-2026-43499, soprannominata in modo non ufficiale GhostLock. Il problema riguarda il codice rtmutex e il meccanismo futex con eredità di priorità, e sfruttarla potrebbe consentire a un utente locale non privilegiato di elevare i diritti a root. Secondo AlmaLinux, la vulnerabilità potrebbe essere utilizzata anche da un container per uscire sul host, se il sistema gira su un kernel non aggiornato.
La natura dell'errore è collegata alla funzione remove_waiter() in kernel/locking/rtmutex.c. Come indicato in una descrizione NVD, durante il rollback di proxy-lock nello scenario futex_requeue(), la funzione operava con il task attuale (current), mentre avrebbe dovuto ripulire lo stato del task che stava realmente aspettando la lock (waiter::task). Di conseguenza, lo stato pi_blocked_on potrebbe non essere stato pulito correttamente, lasciando un puntatore pendente e creando le premesse per un use-after-free.
I ricercatori di Nebula Security hanno descritto GhostLock come un errore presente nelle principali distribuzioni di Linux dal 2011. La discussione pubblica sulla vulnerabilità ha aumentato il rischio per server ed ambienti containerizzati: CloudLinux avverte separatamente che per CVE-2026-43499 esiste già una prova di concetto pubblica, pertanto gli amministratori non dovrebbero rimandare l'aggiornamento del kernel.
La correzione upstream implica che remove_waiter() debba utilizzare waiter::task, e non current, in tutte le operazioni correlate. Questo è indicato anche da GitHub Advisory Database, dove vengono elencate le conseguenze dell'errore: rimozione errata da rbtree senza la necessaria lock, stato pi_blocked_on non pulito e funzionamento di rt_mutex_adjust_prio_chain() non con il task corretto.
Si raccomanda agli utenti delle distribuzioni Linux di installare gli aggiornamenti del kernel più recenti dai repository ufficiali. La vulnerabilità è di natura locale, quindi di per sé non consente un accesso remoto, ma nei server multi-utenza, nelle infrastrutture CI, nell'hosting e nei sistemi con container il rischio è notevolmente più elevato: uno sfruttamento riuscito trasforma già l'accesso con privilegi bassi in un controllo completo del sistema.
Fonte: linux.org.ru
