Linux kernel nvme-pci: reset racing controller disable passes bad queue counts to blk-mq

CVSS 4.7CVE-2024-50135Kernel, userspace & hypervisorcurated

Impact

nvme_pci_update_nr_queues() reads dev->online_queues without holding shutdown_lock, so a controller reset running concurrently with nvme_dev_disable() can hand invalid hardware queue counts to blk_mq_update_nr_hw_queues(). The reported symptom is a WARN out of pci_irq_get_affinity() on the nvme-reset workqueue, with the block layer remapping queues against state that is being torn down underneath it. GPU nodes lean on local NVMe for dataset caches and checkpoint scratch, and this fires during exactly the events an operator cannot avoid - controller resets, surprise removal, a drive going unhealthy - so a flapping NVMe device can leave the storage stack on that node in a state that needs a reboot rather than a retry.

Who can reach it

Local and administrative. It requires a concurrent NVMe controller reset and disable/shutdown on the same device - hotplug, device error recovery or shutdown - not any action available to a tenant workload.

What to do

Patch the kernel to a stable release containing the linked fix, which takes shutdown_lock and bails out if nvme_dev_disable() has run, then reboot each node. No mitigation short of avoiding NVMe resets, which is not something an operator controls. The record lists stable commits with no named fixed version.

References

https://nvd.nist.gov/vuln/detail/CVE-2024-50135 https://git.kernel.org/stable/c/0beb55fc6086c86eb07954c914e728a8cb0cd57e https://git.kernel.org/stable/c/b33e49a5f254474b33ce98fd45dd0ffdc247a0be

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.