CVE-2026-98617 in Linux
Resumen
por VulDB • 2026-10-19
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:
eth: fbnic: usar el puntero napi de la cola Rx para encontrar el vector napi
La gestión de colas mediante ndos selecciona el vector napi para una cola Rx con: nv = fbn->napi[idx % fbn->num_napi];
El problema es que esto solo es correcto en los casos donde no hay vectores Tx independientes. En esos casos, se asignaban primero los vectores Tx y luego los Rx, por lo que las colas apuntaban a vectores NAPI de Tx en lugar de los de Rx.
La mapeo que desean los ndos ya está registrado. fbnic_set_netif_napi() la publica con netif_queue_set_napi(), que almacena el puntero napi en netdev_rx_queue.napi, y fbnic_reset_netif_napi() lo borra de nuevo. Ambas funciones se ejecutan bajo el bloqueo de instancia de netdev que también mantienen los ndos de gestión de colas, por lo que el puntero puede leerse directamente.
Úselo y elimine la división. El puntero es NULL exactamente mientras la ruta de datos está inactiva, por lo que fbnic_queue_mem_alloc() puede rechazar ese caso en lugar de acceder a un estado liberado: netdev_rx_queue_restart() lo llama antes de probar netif_running(), y fbnic_pm_suspend() deja netif_running() como verdadero durante una recuperación PCIe que nunca se completa, por lo que un reinicio de cola puede llegar después de que fbnic_stop() haya liberado los anillos y los vectores. fbnic_stop() borra la asociación en fbnic_reset_netif_queues() antes de fbnic_free_napi_vectors(), por lo que el NULL se publica siempre primero. fbnic_queue_start() y fbnic_queue_stop() no necesitan su propia comprobación, ya que netdev_rx_queue_reconfig() solo las alcanza una vez que fbnic_queue_mem_alloc() ha tenido éxito bajo el mismo bloqueo de instancia.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.