CVE-2026-80775 in Linux
Riassunto
di VulDB • 04/09/2026
Nel kernel Linux è stata risolta la seguente vulnerabilità:
futex: Correzione di una race condition sull'allocazione iniziale di mm->futex.phash.ref
La funzione futex_hash_allocate() alloca mm->futex.phash.ref senza alcun blocco. La commit d9b05321e21e ("futex: Move futex_hash_free() back to __mmput()") ha spostato l'allocazione qui e ha assunto che il processo avesse un solo thread in quel momento.
La commit ee9dce44362b ("futex: Drop CLONE_THREAD requirement for private default hash alloc") ha ampliato need_futex_hash_allocate_default() per coprire qualsiasi clone con CLONE_VM, ma ha escluso vfork perché il genitore è sospeso e non può essere soggetto a race condition.
Questo scenario non vale più quando vfork viene annidato. Se un figlio creato tramite vfork chiama nuovamente vfork e successivamente viene ucciso con SIGKILL, il genitore viene rilasciato dall'attesa di vfork ed esegue in concorrenza con il nipote nello stesso mm (mm). Nessuno dei due ha passato attraverso futex_hash_allocate_default().
Quando entrambi chiamano prctl(PR_FUTEX_HASH, PR_FUTEX_HASH_SET_SLOTS) contemporaneamente, ciascuno vede mm->futex.phash.ref come NULL e memorizza il proprio contatore percpu. Solo l'ultima scrittura sopravvive. Il contatore scritto per primo non è più raggiungibile dal mm, quindi i riferimenti su di esso non vengono visti da __futex_ref_atomic_end(). Una hash privata che ha ancora riferimenti viene quindi considerata morta e liberata, mentre un task che detiene ancora una delle sue bucket scrive in memoria già liberata all'interno di futex_q_lock().
Memorizzare il contatore una sola volta con cmpxchg() e far sì che chi perde la race esegua free_percpu sul proprio. La referenza iniziale deve essere acquisita prima della scrittura, altrimenti un altro task può installare una hash privata mentre il contatore è ancora 0.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.