CVE-2024-53169: nvme-fabrics: fix kernel crash while shutting down controller

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

nvme-fabrics: fix kernel crash while shutting down controller

The nvme keep-alive operation, which executes at a periodic interval, could potentially sneak in while shutting down a fabric controller. This may lead to a race between the fabric controller admin queue destroy code path (invoked while shutting down controller) and hw/hctx queue dispatcher called from the nvme keep-alive async request queuing operation. This race could lead to the kernel crash shown below:

Call Trace: autoremovewakefunction+0x0/0xbc (unreliable) blkmqscheddispatchrequests+0x114/0x24c blkmqscheddispatchrequests+0x44/0x84 blkmqrunhwqueue+0x140/0x220 nvmekeepalivework+0xc8/0x19c [nvmecore] processonework+0x200/0x4e0 workerthread+0x340/0x504 kthread+0x138/0x140 startkernelthread+0x14/0x18

While shutting down fabric controller, if nvme keep-alive request sneaks in then it would be flushed off. The nvmekeepaliveendio function is then invoked to handle the end of the keep-alive operation which decrements the admin->qusagecounter and assuming this is the last/only request in the admin queue then the admin->qusagecounter becomes zero. If that happens then blk-mq destroy queue operation (blkmqdestroy queue()) which could be potentially running simultaneously on another cpu (as this is the controller shutdown code path) would forward progress and deletes the admin queue. So, now from this point onward we are not supposed to access the admin queue resources. However the issue here's that the nvme keep-alive thread running hw/hctx queue dispatch operation hasn't yet finished its work and so it could still potentially access the admin queue resource while the admin queue had been already deleted and that causes the above crash.

The above kernel crash is regression caused due to changes implemented in commit a54a93d0e359 ("nvme: move stopping keep-alive into nvmeuninitctrl()"). Ideally we should stop keep-alive before destroyin g the admin queue and freeing the admin tagset so that it wouldn't sneak in during the shutdown operation. However we removed the keep alive stop operation from the beginning of the controller shutdown code path in commit a54a93d0e359 ("nvme: move stopping keep-alive into nvmeuninitctrl()") and added it under nvmeuninitctrl() which executes very late in the shutdown code path after the admin queue is destroyed and its tagset is removed. So this change created the possibility of keep-alive sneaking in and interfering with the shutdown operation and causing observed kernel crash.

To fix the observed crash, we decided to move nvmestopkeepalive() from nvmeuninitctrl() to nvmeremoveadmintagset(). This change would ensure that we don't forward progress and delete the admin queue until the keep- alive operation is finished (if it's in-flight) or cancelled and that would help contain the race condition explained above and hence avoid the crash.

Moving nvmestopkeepalive() to nvmeremoveadmintagset() instead of adding nvmestopkeepalive() to the beginning of the controller shutdown code path in nvmestopctrl(), as was the case earlier before commit a54a93d0e359 ("nvme: move stopping keep-alive into nvmeuninitctrl()"), would help save one callsite of nvmestopkeepalive().