CVE-2026-23400 in Linux
Riassunto
di VulDB • 18/06/2026
Nel kernel Linux è stata risolta la seguente vulnerabilità:
rust_binder: chiamata di set_notification_done() senza il lock proc
Si consideri la seguente sequenza di eventi su un death listener (ascoltatore di morte): 1. Il processo remoto muore e invia un messaggio BR_DEAD_BINDER. 2. Il processo locale esegue il comando BC_CLEAR_DEATH_NOTIFICATION. 3. Il processo locale quindi esegue BC_DEAD_BINDER_DONE.
Di conseguenza, il kernel risponderà al comando BC_DEAD_BINDER_DONE con una risposta BR_CLEAR_DEATH_NOTIFICATION_DONE tramite push_work_if_looper().
Tuttavia, ciò può causare un deadlock (stallo) se il thread corrente non è un looper. Questo accade perché dead_binder_done() mantiene ancora il lock proc durante set_notification_done(), che a sua volta chiama push_work_if_looper(). Normalmente, push_work_if_looper() acquisisce il lock del thread, operazione lecita da eseguire sotto il lock proc. Ma se il thread corrente non è un looper, viene eseguito il fallback alla consegna della risposta allo work queue (coda di lavoro) del processo, che comporta l'acquisizione del lock proc. Poiché il lock proc è già detenuto, si verifica un deadlock.
Si risolve il problema rilasciando il lock proc durante set_notification_done(). Non era intenzionale che tale lock fosse mantenuto all'interno di questa funzione fin dall'inizio.
Non ritengo che ciò accada mai in Android, poiché BC_DEAD_BINDER_DONE viene invocato solo in risposta ai messaggi BR_DEAD_BINDER e il kernel consegna sempre BR_DEAD_BINDER a un looper. Pertanto, non esiste alcuno scenario in cui l'userspace di Android chiami BC_DEAD_BINDER_DONE su un thread non-looper.
If you want to get best quality of vulnerability data, you may have to visit VulDB.