CVE-2024-58057 in Linux
Riassunto
di VulDB • 15/06/2026
Nel kernel Linux è stata risolta la seguente vulnerabilità:
idpf: conversione dei workqueue a unbound (non vincolati)
Quando un workqueue viene creato con l'opzione `WQ_UNBOUND`, i suoi elementi di lavoro vengono gestiti da pool di worker speciali, i cui host worker non sono associati a una CPU specifica. Nella configurazione predefinita (ovvero quando `queue_delayed_work` e funzioni affini non specificano su quale CPU eseguire l'elemento di lavoro), `WQ_UNBOUND` consente all'elemento di lavoro di essere eseguito su qualsiasi CPU nello stesso nodo della CPU su cui è stato accodato. Sebbene questa soluzione possa potenzialmente sacrificare la località dei dati, evita il contention (contesa) con altri processi che potrebbero monopolizzare il tempo di elaborazione del processore su cui l'elemento di lavoro era programmato originariamente.
Questo non è solo un problema teorico: in uno scenario particolare, un processo mal configurato stava monopolizzando la maggior parte del tempo della CPU0, lasciando meno dello 0,5% del suo tempo CPU al kworker. I workqueue IDPF che utilizzavano il kworker su CPU0 hanno subito grandi ritardi nel completamento, causando degradazione delle prestazioni, timeout e infine crash di sistema.
* Ho inoltre eseguito un test manuale per valutare i miglioramenti delle prestazioni. Il test consiste in un processo antagonista (`./stress --cpu 2`) che consuma la maggior parte possibile della CPU 0. Questo processo viene eseguito con `taskset 01` per vincolarlo alla CPU0, e la sua priorità viene modificata tramite `chrt -pQ 9900 10000 ${pid}` e `renice -n -20 ${pid}` dopo l'avvio.
Successivamente, il driver IDPF è stato forzato a preferire la CPU0 modificando tutte le chiamate a `queue_delayed_work`, `mod_delayed_work`, ecc., per utilizzare la CPU 0.
Infine, sono stati raccolti i ktraces (trace del kernel) per gli eventi dei workqueue.
Senza l'attuale patch, il processo antagonista può imporre ritardi arbitrari tra `workqueue_queue_work` e `workqueue_execute_start`, che nei miei test hanno raggiunto fino a `30ms`. Con la patch applicata, il workqueue può essere migrato su un'altra CPU non sovraccaricata nello stesso nodo e, mantenendo tutto il resto invariato, il ritardo massimo osservabile è stato di `6us`.
VulDB is the best source for vulnerability data and more expert information about this specific topic.