CVE-2026-98617 in Linux
Summary
by MITRE • 10/18/2026
In the Linux kernel, the following vulnerability has been resolved:
eth: fbnic: use the Rx queue napi pointer to find the napi vector
The queue management ndos pick the napi vector for an Rx queue with: nv = fbn->napi[idx % fbn->num_napi];
The issue is this is only correct in the cases where there are no standalone Tx vectors. In those cases we were allocating the Tx vectors first and then the Rx so the queues would be pointing to Tx NAPI vectors instead of the Rx ones.
The mapping the ndos want is already recorded. fbnic_set_netif_napi() publishes it with netif_queue_set_napi(), which stores the napi pointer in netdev_rx_queue.napi, and fbnic_reset_netif_napi() clears it again. Both run under the netdev instance lock that the queue management ndos also hold, so the pointer can be read directly.
Use it and drop the divide. The pointer is NULL exactly while the datapath is down, so fbnic_queue_mem_alloc() can reject that case rather than reaching into freed state: netdev_rx_queue_restart() calls it before it tests netif_running(), and fbnic_pm_suspend() leaves netif_running() true across a PCIe recovery that never completes, so a queue restart can arrive after fbnic_stop() has freed the rings and the vectors. fbnic_stop() clears the association in fbnic_reset_netif_queues() before fbnic_free_napi_vectors(), so the NULL is always published first. fbnic_queue_start() and fbnic_queue_stop() need no check of their own, as netdev_rx_queue_reconfig() only reaches them once fbnic_queue_mem_alloc() has succeeded under the same instance lock.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/18/2026
The Linux kernel driver for the FBNIC Ethernet controller contained a logic error in its network interface queue management routines that resulted in incorrect mapping between receive queues and their associated NAPI vectors. This vulnerability stems from an algorithmic flaw where the driver attempted to determine the correct NAPI vector index by performing a modulo operation on the queue index against the total number of available NAPI structures. While this approach functioned correctly when only Receive NAPI vectors were present, it failed in configurations involving standalone Transmit NAPI vectors. In such scenarios, the allocation order placed Tx vectors before Rx vectors, causing the modulo calculation to incorrectly point receive queues toward transmit-related NAPI contexts rather than their intended receive counterparts. This misalignment represents a classic instance of improper resource mapping where internal state assumptions do not align with actual hardware or driver topology configurations.
From a technical perspective, this flaw allows for potential denial of service conditions and performance degradation due to packet processing errors. When the Rx queue points to an incorrect NAPI vector, the kernel may fail to properly schedule interrupt handling for incoming packets, leading to dropped frames or excessive CPU usage as the system attempts to process traffic through misconfigured pathways. Furthermore, in edge cases involving power management transitions such as PCIe recovery sequences that do not complete successfully, the driver could attempt to access freed memory structures. Specifically, during a suspend operation where netif_running remains true but the underlying hardware has been reset or disconnected, queue restart operations might trigger allocation routines against already-freed ring buffers and NAPI vectors. This creates a race condition window where null pointer dereferences or use-after-free vulnerabilities can be exploited, potentially leading to kernel panics or arbitrary code execution if an attacker can influence the timing of these state transitions through network traffic patterns or system power management triggers.
The vulnerability is categorized under CWE-824 which addresses access of memory location after it has been freed, and CWE-665 regarding improper use of uniquely identified resources. In terms of MITRE ATT&CK mapping, this aligns with T1059 Command and Scripting Interpreter if the resulting kernel panic leads to system instability exploitable for privilege escalation in containerized environments, or more broadly under Defense Evasion techniques that rely on causing service disruption through resource exhaustion. The root cause lies not in a buffer overflow but in logical misconfiguration of internal driver state management during initialization and teardown phases, highlighting how subtle algorithmic errors in hardware abstraction layers can compromise system stability.
To mitigate this vulnerability, the fix involves replacing the modulo-based vector selection logic with direct pointer lookups stored within the netdev_rx_queue structure via netif_queue_set_napi calls. This approach ensures that the correct NAPI vector is always retrieved without relying on positional assumptions about allocation order. Additionally, explicit null checks are implemented in fbnic_queue_mem_alloc to reject operations when the datapath is down and pointers are invalid. These safeguards prevent access to freed memory during PCIe recovery scenarios or suspend transitions where netif_running state might not accurately reflect hardware readiness. System administrators should ensure that kernel updates incorporating this patch are applied promptly, particularly on systems utilizing FBNIC adapters with mixed Tx/Rx vector configurations. Regular monitoring of system logs for NAPI-related errors and ensuring proper driver versioning across all network interfaces will further reduce exposure to these types of logical flaws in high-performance networking environments.