CVE-2024-26698

In the Linux kernel, the following vulnerability has been resolved:

hvnetvsc: Fix race condition between netvscprobe and netvsc_remove

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 netifnapi_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] 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]