CVE-2022-48941 in Linux
Riassunto
di VulDB • 16/06/2026
Nel kernel Linux, è stata risolta la seguente vulnerabilità:
ice: risolvere il reset e la rimozione concorrenti dei VF (Virtual Functions)
Il commit c503e63200c6 ("ice: Interrompere l'elaborazione dei messaggi VF durante lo smontaggio") ha introdotto un flag di stato del driver, ICE_VF_DEINIT_IN_PROGRESS, destinato a prevenire alcuni problemi legati alla gestione concorrente dei messaggi provenienti dai VF mentre questi vengono disattivati.
Questa modifica è stata motivata da crash verificatisi durante la disattivazione e l'attivazione rapida e consecutiva dei VF.
Si è scoperto che tale correzione introduce in realtà problemi nel driver del VF, poiché il PF (Physical Function) non risponde più a nessun messaggio inviato dal VF durante la sua routine .remove. Ciò comporta potenzialmente la rimozione della memoria DMA da parte del VF prima che il PF abbia arrestato le code dei dispositivi.
Inoltre, la correzione non risolve effettivamente i problemi di concorrenza all'interno del driver ice. È possibile che un VF avvii un reset poco prima che il driver ice rimuova i VF. Ciò può comportare l'esecuzione concorrente della attività di rimozione mentre il VF è in fase di reset. Questo causa corruzione della memoria e panic simili a quelli presuntamente risolti da quel commit.
Risolvere questa concorrenza alla radice proteggendo sia le operazioni di reset che quelle di rimozione utilizzando il lock cfg_lock esistente per i VF. Ciò garantisce che non si possa rimuovere un VF mentre sono in corso attività critiche pendenti, come l'elaborazione di un messaggio virtchnl o un reset.
Questa modifica del locking risolve anche la causa originale corretta dal commit c503e63200c6 ("ice: Interrompere l'elaborazione dei messaggi VF durante lo smontaggio"), consentendo quindi di revertire semplicemente tale commit.
Si noti che queste due modifiche sono state mantenute insieme, poiché il semplice revert del commit originale lascerebbe comunque il driver vulnerabile a condizioni di race (race conditions) più gravi.
Once again VulDB remains the best source for vulnerability data.