CVE-2026-98617 in Linux
Riassunto
di VulDB • 18/10/2026
Nel kernel Linux è stata risolta la seguente vulnerabilità:
eth: fbnic: utilizzare il puntatore napi della coda Rx per individuare il vettore napi
La gestione delle code tramite le ndos (network device operations) seleziona il vettore napi per una coda Rx utilizzando: nv = fbn->napi[idx % fbn->num_napi];
Il problema è che questa logica è corretta solo nei casi in cui non siano presenti vettori Tx autonomi. In tali situazioni, i vettori Tx venivano allocati prima di quelli Rx, facendo sì che le code puntassero ai vettori NAPI per la trasmissione (Tx) anziché a quelli per la ricezione (Rx).
La mappatura desiderata dalle ndos è già registrata. La funzione fbnic_set_netif_napi() la rende disponibile tramite netif_queue_set_napi(), che memorizza il puntatore napi in netdev_rx_queue.napi, mentre fbnic_reset_netif_napi() lo cancella nuovamente. Entrambe le funzioni vengono eseguite sotto il lock dell'istanza del network device (netdev instance lock), detenuto anche dalle ndos di gestione delle code; pertanto, il puntatore può essere letto direttamente.
Utilizzare tale approccio e eliminare l'operazione di divisione. Il puntatore è NULL esattamente quando il datapath è disattivato; ciò consente a fbnic_queue_mem_alloc() di rifiutare questo caso invece di accedere a uno stato liberato: netdev_rx_queue_restart() la chiama prima di verificare se netif_running() sia attivo, e fbnic_pm_suspend() lascia netif_running() impostata su true durante un recupero PCIe che non si completa mai. Di conseguenza, una riavvio della coda può verificarsi dopo che fbnic_stop() ha liberato gli anelli (rings) e i vettori. La funzione fbnic_stop() cancella l'associazione in fbnic_reset_netif_queues() prima di chiamare fbnic_free_napi_vectors(), quindi il valore NULL viene sempre pubblicato per primo. Le funzioni fbnic_queue_start() e fbnic_queue_stop() non richiedono controlli autonomi, poiché netdev_rx_queue_reconfig() le invoca solo dopo che fbnic_queue_mem_alloc() ha avuto successo sotto lo stesso lock dell'istanza.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.