UBUNTU-CVE-2024-50135: Race Condition
In the Linux kernel, the following vulnerability has been resolved: nvme-pci: fix race condition between reset and nvmedevdisable() nvmedevdisable() modifies the dev->onlinequeues field, therefore nvmepciupdatenrqueues() should avoid racing against it, otherwise we could end up passing invalid values to blkmqupdatenrhwqueues(). WARNING: CPU: 39 PID: 61303 at drivers/pci/msi/api.c:347 pciirqgetaffinity+0x187/0x210 Workqueue: nvme-reset-wq nvmeresetwork [nvme] RIP: 0010:pciirqgetaffinity+0x187/0x210 Call Trace: <TASK> ? blkmqpcimapqueues+0x87/0x3c0 ? pciirqgetaffinity+0x187/0x210 blkmqpcimapqueues+0x87/0x3c0 nvmepcimapqueues+0x189/0x460 [nvme] blkmqupdatenrhwqueues+0x2a/0x40 nvmeresetwork+0x1be/0x2a0 [nvme] Fix the bug by locking the shutdownlock mutex before using dev->onlinequeues. Give up if nvmedevdisable() is running or if it has been executed already.
Affected Software
Frequently Asked Questions
Which Ubuntu kernel packages are identified as affected?
The affected software list includes ubuntu/linux, ubuntu/linux-fips, ubuntu/linux-azure, ubuntu/linux-aws-fips, ubuntu/linux-azure-fips, ubuntu/linux-gcp-fips, ubuntu/linux-gcp, and ubuntu/linux-oracle. The issue is in the nvme-pci driver path.
How can I tell whether this race has occurred?
A system may log a CPU warning from pci_irq_get_affinity during nvme_reset_work on the nvme-reset-wq workqueue. The reported call trace includes blk_mq_pci_map_queues, nvme_pci_map_queues, blk_mq_update_nr_hw_queues, and nvme_reset_work.
What condition triggers the problem?
The race occurs when nvme_pci_update_nr_queues() uses dev->online_queues while nvme_dev_disable() is modifying that field. This can cause invalid values to be passed to blk_mq_update_nr_hw_queues().