CVE-2024-26698: hv_netvsc: Fix race condition between netvsc_probe and netvsc_remove
In the Linux kernel, the following vulnerability has been resolved:
hvnetvsc: Fix race condition between netvscprobe and netvscremove
In commit ac5047671758 ("hvnetvsc: Disable NAPI before closing the VMBus channel"), napidisable was getting called for all channels, including all subchannels without confirming if they are enabled or not.
This caused hvnetvsc getting hung at napidisable, when netvscprobe() has finished running but nvdev->subchanwork has not started yet. netvscsubchanwork() -> rndissetsubchannel() has not created the sub-channels and because of that netvscscopen() is not running. netvscremove() calls cancelworksync(&nvdev->subchanwork), for which netvscsubchanwork did not run.
netifnapiadd() sets the bit NAPISTATESCHED because it ensures NAPI cannot be scheduled. Then netvscscopen() -> napienable will clear the NAPIFSTATESCHED bit, so it can be scheduled. napidisable() does the opposite.
Now during netvscdeviceremove(), when napidisable is called for those subchannels, napidisable gets stuck on infinite msleep.
This fix addresses this problem by ensuring that napidisable() is not getting called for non-enabled NAPI struct. But netifnapidel() 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] scheduletimeout+0x87/0x140 [ 654.585463] ? bpftracetickstop+0x20/0x20 [ 654.590291] msleep+0x2d/0x40 [ 654.593625] napidisable+0x2b/0x80 [ 654.597437] netvscdeviceremove+0x8a/0x1f0 [hvnetvsc] [ 654.603935] rndisfilterdeviceremove+0x194/0x1c0 [hvnetvsc] [ 654.611101] ? dowaitintr+0xb0/0xb0 [ 654.615753] netvscremove+0x7c/0x120 [hvnetvsc] [ 654.621675] vmbusremove+0x27/0x40 [hvvmbus]
Other sources
In the Linux kernel, the following vulnerability has been resolved:
hvnetvsc: Fix race condition between netvscprobe and netvscremove
In commit ac5047671758 ("hvnetvsc: Disable NAPI before closing the VMBus channel"), napidisable was getting called for all channels, including all subchannels without confirming if they are enabled or not.
This caused hvnetvsc getting hung at napidisable, when netvscprobe() has finished running but nvdev->subchanwork has not started yet. netvscsubchanwork() -> rndissetsubchannel() has not created the sub-channels and because of that netvscscopen() is not running. netvscremove() calls cancelworksync(&nvdev->subchanwork), for which netvscsubchanwork did not run.
netifnapiadd() sets the bit NAPISTATESCHED because it ensures NAPI cannot be scheduled. Then netvscscopen() -> napienable will clear the NAPIFSTATESCHED bit, so it can be scheduled. napidisable() does the opposite.
Now during netvscdeviceremove(), when napidisable is called for those subchannels, napidisable gets stuck on infinite msleep.
This fix addresses this problem by ensuring that napidisable() is not getting called for non-enabled NAPI struct. But netifnapidel() 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] scheduletimeout+0x87/0x140 [ 654.585463] ? bpftracetickstop+0x20/0x20 [ 654.590291] msleep+0x2d/0x40 [ 654.593625] napidisable+0x2b/0x80 [ 654.597437] netvscdeviceremove+0x8a/0x1f0 [hvnetvsc] [ 654.603935] rndisfilterdeviceremove+0x194/0x1c0 [hvnetvsc] [ 654.611101] ? dowaitintr+0xb0/0xb0 [ 654.615753] netvscremove+0x7c/0x120 [hvnetvsc] [ 654.621675] vmbusremove+0x27/0x40 [hvvmbus]
— NVD
In the Linux kernel, the following vulnerability has been resolved:
hvnetvsc: Fix race condition between netvscprobe and netvscremove
The Linux kernel CVE team has assigned CVE-2024-26698 to this issue.
Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024040338-CVE-2024-26698-36ac@gregkh/T
— Red Hat
Affected Software
Remediation
Event History
Frequently Asked Questions
What is the severity of CVE-2024-26698?
CVE-2024-26698 has a moderate severity level due to the potential for race conditions impacting kernel module stability.
How do I fix CVE-2024-26698?
To address CVE-2024-26698, update the Linux kernel to one of the patched versions provided by your distribution, such as Red Hat kernel version 5.10.210 or newer.
Which Linux kernel versions are affected by CVE-2024-26698?
CVE-2024-26698 affects several Linux kernel versions prior to 5.10.210, 5.15.149, 6.1.79, and 6.6.18, among others.
Is CVE-2024-26698 specific to any Linux distributions?
Yes, CVE-2024-26698 primarily affects Red Hat and Debian distributions, as indicated by the specific kernel versions mentioned.
What components are involved in CVE-2024-26698?
CVE-2024-26698 involves the hv_netvsc component of the Linux kernel, specifically regarding the netvsc_probe and netvsc_remove functions.