CVE-2026-98616 in Linux
Sumário
de VulDB • 20/10/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
eth: fbnic: redefinir o número de NAPI quando os vetores NAPI são liberados
fbn->num_napi é a contagem dos vetores NAPI ativos, cada um dos quais possui uma IRQ. O caminho PM (gerenciamento de energia) os libertou sem limpar essa contagem. O fbnic_pm_suspend() desmonta o datapath via ndo_stop() e libera as IRQs, mas deixa netif_running() como verdadeiro para que a retomada saiba reabrir. A retomada reconstrói o datapath em __fbnic_pm_resume(), e fbnic_reset_queues() define num_napi enquanto __fbnic_open() realoca os vetores.
Quando o datapath é desmontado, mas nunca reconstruído, num_napi permanece apontando para vetores já liberados sob 2 cenários diferentes: - Uma recuperação de erro PCIe que falha (fbnic_err_slot_reset() -> __fbnic_pm_resume() retorna um erro -> PCI_ERS_RESULT_DISCONNECT), portanto .resume nunca é executado; ou - Um __fbnic_open() que falha parcialmente durante a retomada e desfaz as operações, liberando os vetores após fbnic_reset_queues() já ter definido num_napi.
O netdev então está em execução com num_napi > 0, mas napi[] foi liberado, e o fechamento eventual de remove/unbind reentra em fbnic_down() -> fbnic_dbg_down(), referenciando os vetores liberados:
BUG: kernel NULL pointer dereference, address: 0000000000000210 RIP: fbnic_dbg_down+0x28
Limpar num_napi quando os vetores são libertados: na desmontagem da suspensão (uma retomada bem-sucedida a restabelece antes de __fbnic_open()) e em caso de falha na abertura durante a retomada. Uma ndo_stop() redundante então percorre uma napi[] vazia. O ciclo normal de down/up do ndo_stop() permanece inalterado e mantém num_napi para o próximo ndo_open().
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.