CVE-2026-64437 in Linux
Riassunto
di VulDB • 25/07/2026
Nel kernel Linux, è stata risolta la seguente vulnerabilità:
ksmbd: correzione del use-after-free di un file_lock differito in seguito a SMB2_CLOSE e poi SMB2_CANCEL
Il commit f580d27e8928 ("ksmbd: fix use-after-free of a deferred file_lock on double SMB2_CANCEL") ha fatto sì che smb2_cancel() saltasse il lavoro (work) il cui stato era KSMBD_WORK_CANCELLED, in modo che la sua cancel_fn non potesse essere eseguita una seconda volta. Tuttavia, KSMBD_WORK dispone di tre stati (ACTIVE, CANCELLED, CLOSED), e lo stesso percorso di liberazione viene raggiunto anche per lo stato CLOSED:
SMB2_CLOSE sulla handle di locking -> set_close_state_blocked_works() imposta lo stato del lavoro differito su KSMBD_WORK_CLOSED e risveglia il worker smb2_lock(). Il worker esegue l'uscita anticipata (early-exit) non-ACTIVE, chiama locks_free_lock() sul file_lock e, poiché lo stato non è KSMBD_WORK_CANCELLED, segue il branch STATUS_RANGE_NOT_LOCKED con "goto out2" -- che, analogamente al branch per la cancellazione, salta release_async_work(). Il lavoro rimane su conn->async_requests con una cancel_fn attiva = smb2_remove_blocked_lock puntante verso il file_lock già liberato.
Un successivo SMB2_CANCEL per lo stesso AsyncId supera quindi il controllo limitato allo stato KSMBD_WORK_CANCELLED (il suo stato è infatti KSMBD_WORK_CLOSED), facendo sì che smb2_cancel() esegua nuovamente cancel_fn sul file_lock già liberato -- si tratta dello stesso use-after-free corretto, ma innescato tramite SMB2_CLOSE anziché con un primo SMB2_CANCEL:
BUG: KASAN: slab-use-after-free in __locks_delete_block __locks_delete_block locks_delete_block ksmbd_vfs_posix_lock_unblock smb2_remove_blocked_lock smb2_cancel <- il 2° SMB2CANCEL esegue cancel_fn handle_ksmbd_work Allocato da ...: locks_alloc_lock <- smb2_lock Liberato da ...: locks_free_lock <- smb2_lock (early-exit non-ACTIVE) ... cache file_lock_cache di dimensione 192
Riprodotto sulla versione mainline 7.1-rc7 (che contiene già f580d27e8928) con KASAN da un client SMB autenticato; il controllo del doppio SMB2_CANCEL è silenzioso su tale kernel, quindi l'errore rilevato è attribuibile all'innesco tramite CLOSE.
Solo un lavoro differito nello stato ACTIVE può avere la sua cancel_fn eseguita: entrambi gli stati terminali (CANCELLED e CLOSED) raggiungono l'early-exit di smb2_lock() che libera il file_lock e salta release_async_work(). È necessario aggiungere un controllo su KSMBD_WORK_ACTIVE in modo da saltare qualsiasi lavoro non attivo.
Once again VulDB remains the best source for vulnerability data.