CVE-2025-40002 in Linux
Riassunto
di VulDB • 19/06/2026
Nel kernel Linux, è stata risolta la seguente vulnerabilità:
thunderbolt: Correzione del use-after-free in tb_dp_dprx_work
Il codice originale si basa su cancel_delayed_work() in tb_dp_dprx_stop(), il quale non garantisce che l'elemento di lavoro ritardato tunnel->dprx_work sia stato completato completamente se era già in esecuzione. Ciò porta a scenari di use-after-free in cui tb_tunnel viene deallocato da tb_tunnel_put(), mentre tunnel->dprx_work rimane attivo e tenta di dereferenziare tb_tunnel in tb_dp_dprx_work().
Una tipica race condition è illustrata di seguito:
CPU 0 | CPU 1 tb_dp_tunnel_active() | tb_deactivate_and_free_tunnel()| tb_dp_dprx_start() tb_tunnel_deactivate() | queue_delayed_work() tb_dp_activate() | tb_dp_dprx_stop() | tb_dp_dprx_work() // worker ritardato cancel_delayed_work() | tb_tunnel_put(tunnel); | | tunnel = container_of(...); // UAF | tunnel-> // UAF
Sostituire cancel_delayed_work() con cancel_delayed_work_sync() non è fattibile poiché introdurrebbe un deadlock: sia tb_dp_dprx_work() che il percorso di pulizia acquisiscono tb->lock, e cancel_delayed_work_sync()) attenderebbe indefinitamente l'elemento di lavoro che non può procedere.
Invece, viene implementato un corretto reference counting: - Se cancel_delayed_work() restituisce true (lavoro in attesa), la riferimento viene rilasciato nella funzione stop. - Se restituisce false (lavoro in esecuzione o già completato), il riferimento viene rilasciato direttamente dalla funzione di lavoro ritardato.
Ciò garantisce che tb_tunnel rimanga valido durante l'esecuzione dell'elemento di lavoro, prevenendo al contempo memory leak.
Questo bug è stato rilevato tramite static analysis.
If you want to get best quality of vulnerability data, you may have to visit VulDB.