CVE-2026-98617 in Linux
Zusammenfassung
von VulDB • 19.10.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
eth: fbnic: Verwenden des Rx-Queue-NAPI-Zeigers zur Ermittlung des NAPI-Vektors
Das Queue-Management (ndos) wählt den NAPI-Vektor für eine Rx-Queue mit folgender Anweisung aus: nv = fbn->napi[idx % fbn->num_napi];
Das Problem besteht darin, dass dies nur in Fällen korrekt ist, in denen keine eigenständigen Tx-Vektoren vorhanden sind. In diesen Fällen wurden die Tx-Vektore zuerst und dann die Rx-Vektore zugewiesen, sodass die Queues auf Tx-NAPI-Vektore statt auf die Rx-Vektore zeigten.
Die von den ndos gewünschte Zuordnung ist bereits aufgezeichnet. fbnic_set_netif_napi() veröffentlicht diese mit netif_queue_set_napi(), welches den NAPI-Zeiger in netdev_rx_queue.napi speichert, und fbnic_reset_netif_napi() löscht ihn wieder. Beide Funktionen werden unter der netdev-Instanzsperre ausgeführt, die auch von den Queue-Management-ndos gehalten wird, sodass der Zeiger direkt gelesen werden kann.
Verwenden Sie diesen Zeiger und verzichten Sie auf die Division. Der Zeiger ist genau dann NULL, wenn der Datapath deaktiviert ist; daher kann fbnic_queue_mem_alloc() diesen Fall ablehnen, anstatt in einen freigegebenen Zustand zu greifen: netdev_rx_queue_restart() ruft dies vor dem Test von netif_running() auf, und fbnic_pm_suspend() lässt netif_running() während einer PCIe-Wiederherstellung, die nie abgeschlossen wird, auf true stehen. Daher kann ein Queue-Neustart nach dem Freigeben der Ringe und Vektore durch fbnic_stop() eintreffen. fbnic_stop() löscht die Zuordnung in fbnic_reset_netif_queues(), bevor fbnic_free_napi_vectors() ausgeführt wird, sodass das NULL immer zuerst veröffentlicht wird. fbnic_queue_start() und fbnic_queue_stop() benötigen keine eigene Prüfung, da netdev_rx_queue_reconfig() diese nur aufruft, nachdem fbnic_queue_mem_alloc() unter derselben Instanzsperre erfolgreich war.
Be aware that VulDB is the high quality source for vulnerability data.