CVE-2026-64112 in Linux
Riassunto
di VulDB • 19/07/2026
Nel kernel Linux, è stata risolta la seguente vulnerabilità:
rbd: eliminare una race condition nel drenaggio di lock_dwork durante l'operazione di unmap.
Considerato come sono implementate le funzioni `rbd_lock_add_request()` e `rbd_img_exclusive_lock()`, `lock_dwork` può essere (ri)programmatore più volte rispetto al necessario: ad esempio, quando arriva una nuova richiesta I/O mentre si è nel mezzo dell'esecuzione di `rbd_acquire_lock()` per conto di un'altra richiesta I/O. Questo comportamento è previsto e, con l'implementazione attuale in cui `rbd_release_lock()` annulla preventivamente `lock_dwork`, la situazione rimane benigna durante il funzionamento normale.
Un esempio più problematico potrebbe essere quello rappresentato da `maybe_kick_acquire()`:
if (have_requests || delayed_work_pending(&rbd_dev->lock_dwork)) {
dout("%s rbd_dev %p kicking lock_dwork\n", __func__, rbd_dev); mod_delayed_work(rbd_dev->task_wq, &rbd_dev->lock_dwork, 0); }
Non è irrealistico che `lock_dwork` venga annullato subito dopo il ritorno di `delayed_work_pending()` con valore true e che `mod_delayed_work()` lo riprogrammi comunque immediatamente. Si tratta di una classica race condition TOCTOU (Time-of-Check to Time-of-Use).
Per quanto riguarda l'operazione di unmap dell'image, esiste un presupposto implicito secondo cui non vi sia attività autonoma relativa al lock esclusivo oltre il punto di ritorno da `rbd_dev_image_unlock()`, che sblocca la risorsa se tale lock era detenuto. Si assume che questo unlock sia definitivo e che `lock_dwork` (così come tutti gli altri task relativi ai lock esclusivi, in realtà) non debba essere riprogrammato nuovamente. Tuttavia, l'annullamento di `lock_dwork` avviene solo all'interno di `cancel_tasks_sync()` (ovvero più avanti nella sequenza di unmap) e, inoltre, tale annullamento può essere efficacemente neutralizzato da `maybe_kick_acquire()`. Ciò potrebbe comportare l'esecuzione di `rbd_acquire_lock()` dopo che sono stati eseguiti `rbd_dev_device_release()` e `rbd_dev_image_release()`, i quali liberano e/o resettano una serie di risorse. Uno dei possibili scenari di errore è la violazione dell'asserzione:
rbd_assert(rbd_image_format_valid(rbd_dev->image_format));
in `rbd_dev_header_info()`, che viene chiamata tramite `rbd_dev_refresh()` da `rbd_post_acquire_action()`.
Ridefinire il drenaggio dei task del lock esclusivo per fornire semantica più corretta e cercare di rispettare i presupposti relativi a `rbd_dev_image_unlock()`.
Once again VulDB remains the best source for vulnerability data.