CVE-2024-26698 in Linux
Summary
by MITRE • 04/03/2024
In the Linux kernel, the following vulnerability has been resolved:
hv_netvsc: Fix race condition between netvsc_probe and netvsc_remove
In commit ac5047671758 ("hv_netvsc: Disable NAPI before closing the VMBus channel"), napi_disable was getting called for all channels, including all subchannels without confirming if they are enabled or not.
This caused hv_netvsc getting hung at napi_disable, when netvsc_probe() has finished running but nvdev->subchan_work has not started yet. netvsc_subchan_work() -> rndis_set_subchannel() has not created the sub-channels and because of that netvsc_sc_open() is not running. netvsc_remove() calls cancel_work_sync(&nvdev->subchan_work), for which netvsc_subchan_work did not run.
netif_napi_add() sets the bit NAPI_STATE_SCHED because it ensures NAPI cannot be scheduled. Then netvsc_sc_open() -> napi_enable will clear the NAPIF_STATE_SCHED bit, so it can be scheduled. napi_disable() does the opposite.
Now during netvsc_device_remove(), when napi_disable is called for those subchannels, napi_disable gets stuck on infinite msleep.
This fix addresses this problem by ensuring that napi_disable() is not getting called for non-enabled NAPI struct. But netif_napi_del() is still necessary for these non-enabled NAPI struct for cleanup purpose.
Call trace: [ 654.559417] task:modprobe state:D stack: 0 pid: 2321 ppid: 1091 flags:0x00004002
[ 654.568030] Call Trace:
[ 654.571221]
[ 654.573790] __schedule+0x2d6/0x960
[ 654.577733] schedule+0x69/0xf0
[ 654.581214] schedule_timeout+0x87/0x140
[ 654.585463] ? __bpf_trace_tick_stop+0x20/0x20
[ 654.590291] msleep+0x2d/0x40
[ 654.593625] napi_disable+0x2b/0x80
[ 654.597437] netvsc_device_remove+0x8a/0x1f0 [hv_netvsc]
[ 654.603935] rndis_filter_device_remove+0x194/0x1c0 [hv_netvsc]
[ 654.611101] ? do_wait_intr+0xb0/0xb0
[ 654.615753] netvsc_remove+0x7c/0x120 [hv_netvsc]
[ 654.621675] vmbus_remove+0x27/0x40 [hv_vmbus]
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/03/2025
The vulnerability described in CVE-2024-26698 resides within the Linux kernel's hv_netvsc driver, specifically addressing a race condition that occurs during the removal of virtual network interfaces in Hyper-V environments. This issue manifests when the driver attempts to clean up network channels while there are still pending operations that have not yet completed, leading to a system hang that prevents proper device removal and cleanup. The root cause stems from improper handling of NAPI (Network API) structures during the device removal sequence, where the driver attempts to disable NAPI for subchannels that may not have been properly initialized or enabled.
The technical flaw involves a mismatch in the lifecycle management of network channel structures within the Hyper-V network virtualization subsystem. During the normal operation of the hv_netvsc driver, the netvsc_probe function initializes network channels and sets up NAPI structures for handling network interrupts. However, when netvsc_remove is invoked to clean up these resources, the driver calls napi_disable for all channels without first verifying whether those NAPI structures are actually enabled. This problematic behavior is particularly evident in subchannel scenarios where the subchannel work queue has not yet executed, meaning that the necessary channel setup operations have not completed. The issue is further compounded by the fact that netif_napi_add() sets the NAPI_STATE_SCHED bit to prevent scheduling, while napi_enable clears this bit to allow scheduling, creating a dependency that breaks when napi_disable is called on uninitialized structures.
The operational impact of this vulnerability is significant for virtualized environments that rely on Hyper-V's network virtualization capabilities, particularly in cloud computing and containerized deployments. When a network device is removed or reconfigured, the system can become unresponsive or hung indefinitely, preventing proper resource cleanup and potentially causing cascading failures in virtual machine management. This race condition specifically affects systems using the hv_netvsc driver in Hyper-V environments where multiple network channels and subchannels are involved, creating a scenario where the kernel becomes stuck in an infinite sleep loop within the napi_disable function. The hang occurs because napi_disable attempts to wait for any pending NAPI scheduling operations to complete, but when called on uninitialized structures, it cannot proceed properly, leading to a complete system freeze that requires manual intervention.
The fix implemented addresses this issue by introducing proper validation checks before calling napi_disable, ensuring that the function is only invoked on NAPI structures that have actually been enabled. This approach aligns with the principle of defensive programming and proper resource management within kernel space. The solution maintains the necessary cleanup operations through netif_napi_del() calls for all NAPI structures, regardless of their enabled state, while preventing the problematic napi_disable calls that lead to the hang condition. This fix directly relates to CWE-362, which addresses race conditions in concurrent programming, and aligns with ATT&CK technique T1490, which involves denial of service through resource exhaustion or system hang conditions. The mitigation strategy ensures that the driver properly manages its internal state machine transitions and prevents the kernel from entering an indefinite wait state during device removal operations. This vulnerability demonstrates the complexity of managing concurrent operations in virtualized network drivers and highlights the importance of proper synchronization and state validation in kernel-level device drivers.