CVE-2026-99048 in Linux
Summary
by MITRE • 10/23/2026
In the Linux kernel, the following vulnerability has been resolved:
gve: fix napi_disable deadlock when attempting to disable XSK pools
When disabling XSK pools, GVE calls the unlocked versions of napi_disable and napi_enable. However, the netdev lock has already been acquired before ndo_bpf is called because GVE supports queue management ops. Calling the unlocked versions of napi_disable/enable results in a deadlock when attempting to disable XSK pools, as the thread attempts to re-acquire a lock it already holds.
Update the NAPI calls to use the locked versions.
This issue was found in production.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/23/2026
The General Virtual Ethernet driver for Linux kernels contains a concurrency flaw within its handling of eXpress Data Path socket pools, specifically during the disablement sequence. This vulnerability manifests as a deadlock condition that can render network interfaces unresponsive or cause kernel hangs under specific operational conditions involving XSK pool management. The root cause lies in an incorrect synchronization mechanism where the driver invokes unlocked variants of NAPI (Network API) functions while holding locks that those same functions attempt to acquire internally, creating a classic self-deadlock scenario due to non-reentrant locking semantics in the Linux kernel networking subsystem.
The technical flaw originates from the interaction between queue management operations and BPF program execution hooks within the GVE driver architecture. When the system attempts to disable XSK pools via the ndo_bpf operation, the netdev lock is already acquired by the calling context because GVE supports specific queue management operations that require exclusive access to network device structures. Inside this locked context, the code path calls napi_disable and napi_enable functions without acquiring additional locks, assuming they are safe to call in a non-locked environment. However, these standard NAPI API versions internally attempt to acquire spinlocks or mutexes associated with the NAPI poll list. Since the thread already holds the netdev lock which is often intertwined with or requires similar synchronization primitives as the NAPI internal locks, the kernel detects that it is attempting to re-acquire a lock it currently owns without proper recursive locking support in this specific context. This results in an immediate deadlock where the execution thread blocks indefinitely waiting for a resource it already holds but cannot release due to the blocking nature of the inner function call.
From a security and operational impact perspective, this vulnerability primarily affects system availability rather than confidentiality or integrity. A local attacker with sufficient privileges to trigger network interface reconfiguration or XSK pool management operations could induce a denial-of-service condition by causing the kernel thread handling these events to hang indefinitely. In production environments, such deadlocks can lead to complete loss of network connectivity for affected interfaces and potentially destabilize the host system if the deadlock propagates to other subsystems waiting on related resources. The fact that this issue was discovered in production highlights its relevance to real-world deployments where dynamic configuration changes are common, particularly in cloud-native or virtualized environments relying heavily on high-performance packet processing features like XDP.
This vulnerability is categorized under CWE-833: Deadlock and aligns with ATT&CK technique T1499: Endpoint Denial of Service, as it involves the exploitation of a resource contention flaw to disrupt service availability. The mitigation strategy implemented in the resolved version addresses this by updating the NAPI calls to use their locked counterparts. By invoking napi_disable_sync or similar synchronized variants that do not attempt to acquire locks already held by the caller, the driver ensures proper lock ordering and prevents recursive acquisition attempts. Administrators should ensure they are running kernel versions where this patch is applied, particularly those utilizing GVE drivers with XSK pool support enabled. Regular updates to the Linux kernel and associated network drivers are essential to maintain system stability in environments requiring high-throughput networking capabilities.