CVE-2024-26698: Vulnerability in Linux Linux
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] <TASK> [ 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]
AI Analysis
Technical Summary
CVE-2024-26698 is a race condition vulnerability in the Linux kernel's hv_netvsc driver, which is part of the Hyper-V network virtualization stack. The vulnerability arises from improper handling of NAPI (New API) state transitions during the probing and removal of network virtual service channels (netvsc_probe and netvsc_remove). Specifically, the issue is caused by calling napi_disable() on NAPI structures that are not enabled, leading to a hang due to an infinite msleep loop. The root cause is that during device removal, napi_disable() is invoked indiscriminately for all channels and subchannels without verifying if they are enabled, causing the kernel to hang when netvsc_probe() has completed but subchannel work has not yet started. The fix ensures napi_disable() is only called on enabled NAPI structs, while netif_napi_del() is still called for cleanup on non-enabled structs. This vulnerability can cause the affected Linux kernel to hang or become unresponsive during device removal operations related to the Hyper-V network driver, potentially leading to denial of service conditions on systems running Linux as guests on Hyper-V virtualization platforms. The issue is specific to the hv_netvsc driver and affects kernel versions containing the commit ac5047671758. No known exploits are currently reported in the wild, and no CVSS score has been assigned yet.
Potential Impact
For European organizations, the impact of CVE-2024-26698 primarily concerns environments running Linux virtual machines on Microsoft Hyper-V hypervisors, especially those utilizing the hv_netvsc network driver. A successful exploitation leads to a kernel hang during device removal, causing denial of service (DoS) on the affected VM. This can disrupt critical network services, degrade availability of cloud or virtualized infrastructure, and impact business continuity. Organizations relying on Hyper-V for private or hybrid cloud deployments, virtual desktop infrastructure (VDI), or network function virtualization (NFV) may experience service interruptions. While this vulnerability does not appear to allow privilege escalation or remote code execution, the DoS impact on critical infrastructure can be significant, especially in high-availability or real-time environments. European sectors such as finance, healthcare, telecommunications, and government that use Hyper-V virtualization with Linux guests are at risk of operational disruptions. Additionally, the complexity of the issue may complicate troubleshooting and recovery, increasing downtime and operational costs.
Mitigation Recommendations
1. Apply the official Linux kernel patches that fix the race condition in the hv_netvsc driver as soon as they become available from trusted Linux distributions or kernel maintainers. 2. For organizations using Hyper-V virtualization, ensure that Linux guest VMs are running updated kernel versions that include this fix. 3. Avoid unnecessary removal or reconfiguration of network devices on Linux guests until patches are applied to prevent triggering the hang. 4. Implement monitoring and alerting for kernel hangs or unresponsive VMs to enable rapid detection and remediation. 5. In environments where patching is delayed, consider isolating critical Linux VMs or limiting network device changes to maintenance windows to reduce impact. 6. Collaborate with Hyper-V platform administrators to coordinate updates and validate compatibility of patched kernels with the Hyper-V host. 7. Review and test backup and recovery procedures to ensure quick restoration of affected VMs in case of hangs. 8. Engage with Linux distribution vendors for backported fixes if using long-term support kernels.
Affected Countries
Germany, United Kingdom, France, Netherlands, Sweden, Finland, Ireland, Belgium, Italy, Spain
CVE-2024-26698: Vulnerability in Linux Linux
Description
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] <TASK> [ 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]
AI-Powered Analysis
Technical Analysis
CVE-2024-26698 is a race condition vulnerability in the Linux kernel's hv_netvsc driver, which is part of the Hyper-V network virtualization stack. The vulnerability arises from improper handling of NAPI (New API) state transitions during the probing and removal of network virtual service channels (netvsc_probe and netvsc_remove). Specifically, the issue is caused by calling napi_disable() on NAPI structures that are not enabled, leading to a hang due to an infinite msleep loop. The root cause is that during device removal, napi_disable() is invoked indiscriminately for all channels and subchannels without verifying if they are enabled, causing the kernel to hang when netvsc_probe() has completed but subchannel work has not yet started. The fix ensures napi_disable() is only called on enabled NAPI structs, while netif_napi_del() is still called for cleanup on non-enabled structs. This vulnerability can cause the affected Linux kernel to hang or become unresponsive during device removal operations related to the Hyper-V network driver, potentially leading to denial of service conditions on systems running Linux as guests on Hyper-V virtualization platforms. The issue is specific to the hv_netvsc driver and affects kernel versions containing the commit ac5047671758. No known exploits are currently reported in the wild, and no CVSS score has been assigned yet.
Potential Impact
For European organizations, the impact of CVE-2024-26698 primarily concerns environments running Linux virtual machines on Microsoft Hyper-V hypervisors, especially those utilizing the hv_netvsc network driver. A successful exploitation leads to a kernel hang during device removal, causing denial of service (DoS) on the affected VM. This can disrupt critical network services, degrade availability of cloud or virtualized infrastructure, and impact business continuity. Organizations relying on Hyper-V for private or hybrid cloud deployments, virtual desktop infrastructure (VDI), or network function virtualization (NFV) may experience service interruptions. While this vulnerability does not appear to allow privilege escalation or remote code execution, the DoS impact on critical infrastructure can be significant, especially in high-availability or real-time environments. European sectors such as finance, healthcare, telecommunications, and government that use Hyper-V virtualization with Linux guests are at risk of operational disruptions. Additionally, the complexity of the issue may complicate troubleshooting and recovery, increasing downtime and operational costs.
Mitigation Recommendations
1. Apply the official Linux kernel patches that fix the race condition in the hv_netvsc driver as soon as they become available from trusted Linux distributions or kernel maintainers. 2. For organizations using Hyper-V virtualization, ensure that Linux guest VMs are running updated kernel versions that include this fix. 3. Avoid unnecessary removal or reconfiguration of network devices on Linux guests until patches are applied to prevent triggering the hang. 4. Implement monitoring and alerting for kernel hangs or unresponsive VMs to enable rapid detection and remediation. 5. In environments where patching is delayed, consider isolating critical Linux VMs or limiting network device changes to maintenance windows to reduce impact. 6. Collaborate with Hyper-V platform administrators to coordinate updates and validate compatibility of patched kernels with the Hyper-V host. 7. Review and test backup and recovery procedures to ensure quick restoration of affected VMs in case of hangs. 8. Engage with Linux distribution vendors for backported fixes if using long-term support kernels.
For access to advanced analysis and higher rate limits, contact root@offseq.com
Technical Details
- Data Version
- 5.1
- Assigner Short Name
- Linux
- Date Reserved
- 2024-02-19T14:20:24.157Z
- Cisa Enriched
- true
- Cvss Version
- null
- State
- PUBLISHED
Threat ID: 682d982ac4522896dcbe3852
Added to database: 5/21/2025, 9:08:58 AM
Last enriched: 6/29/2025, 5:26:58 PM
Last updated: 8/15/2025, 3:47:56 PM
Views: 14
Related Threats
CVE-2025-55455: n/a
HighCVE-2025-8193
UnknownCVE-2025-9356: Stack-based Buffer Overflow in Linksys RE6250
HighCVE-2025-9355: Stack-based Buffer Overflow in Linksys RE6250
HighCVE-2025-43761: CWE-79 Improper Neutralization of Input During Web Page Generation (XSS or 'Cross-site Scripting') in Liferay Portal
MediumActions
Updates to AI analysis are available only with a Pro account. Contact root@offseq.com for access.
External Links
Need enhanced features?
Contact root@offseq.com for Pro access with improved analysis and higher rate limits.