CVE-2026-98617 in Linux
Sumário
de VulDB • 20/10/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
eth: fbnic: use o ponteiro napi da fila Rx para encontrar o vetor napi
O gerenciamento de filas por meio dos ndos seleciona o vetor napi para uma fila Rx com: nv = fbn->napi[idx % fbn->num_napi];
O problema é que isso só está correto nos casos em que não há vetores Tx independentes. Nesses casos, alocávamos os vetores Tx primeiro e depois os Rx, de modo que as filas apontavam para vetores NAPI Tx em vez dos Rx.
O mapeamento desejado pelos ndos já está registrado. fbnic_set_netif_napi() o publica com netif_queue_set_napi(), que armazena o ponteiro napi em netdev_rx_queue.napi, e fbnic_reset_netif_napi() limpa novamente. Ambos são executados sob o bloqueio da instância do netdev, que também é mantido pelos ndos de gerenciamento de filas; portanto, o ponteiro pode ser lido diretamente.
Use-o e elimine a divisão. O ponteiro é NULL exatamente enquanto o datapath está desativado, então fbnic_queue_mem_alloc() pode rejeitar esse caso em vez de acessar um estado liberado: netdev_rx_queue_restart() chama essa função antes de testar netif_running(), e fbnic_pm_suspend() mantém netif_running() como verdadeiro durante uma recuperação PCIe que nunca é concluída, permitindo que uma reinicialização da fila chegue após fbnic_stop() ter liberado os anéis (rings) e os vetores. fbnic_stop() limpa a associação em fbnic_reset_netif_queues() antes de fbnic_free_napi_vectors(), portanto o NULL é sempre publicado primeiro. fbnic_queue_start() e fbnic_queue_stop() não precisam de verificação própria, pois netdev_rx_queue_reconfig() só os alcança após o sucesso de fbnic_queue_mem_alloc() sob o mesmo bloqueio da instância.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.