CVE-2024-50135

What it actually does

A race condition allows nvme_dev_disable() to modify dev->online_queues while nvme_pci_update_nr_queues() concurrently reads the value and passes invalid data to blk_mq_update_nr_hw_queues(), triggering warnings and potential queue mapping failures during device reset.

Why it matters to the business

Systems using NVMe storage may experience unexpected resets, queue misconfigurations, or crashes that interrupt storage I/O and reduce availability of affected Linux servers and appliances.

How an attack unfolds

An attacker with local access triggers repeated NVMe device resets while nvme_dev_disable() runs, winning the race to supply invalid online_queues values that cause blk_mq_update_nr_hw_queues() to operate on inconsistent state and produce kernel warnings or faults.

How to fix it

Update the Linux kernel to a version containing commit 4ed32cc0939b64e3d7b48c8c0d63ea038775f304 or later; apply the equivalent stable or distribution backport that adds shutdown_lock protection around online_queues usage in nvme reset paths.

How to confirm the fix worked

Confirm the patched kernel contains the shutdown_lock acquisition before online_queues reads in nvme_pci_update_nr_queues() and nvme_reset_work(); verify no WARNING at pci_irq_get_affinity during reset workloads and test concurrent reset/disable sequences.

Typical attack path

1. Obtain local code execution on a system with NVMe devices
2. Trigger nvme reset workqueue activity concurrently with device disable paths
3. Force the race on dev->online_queues access
4. Induce invalid queue count passed to block layer resulting in warnings or instability

How to detect it

Search kernel logs for WARNING at pci_irq_get_affinity during nvme-reset-wq activity and stack traces involving blk_mq_pci_map_queues and nvme_reset_work; examine dmesg or journalctl for concurrent nvme disable and queue update events.

What your security team should do

• Prioritize kernel updates on all systems exposing NVMe storage to production workloads
• Monitor vendor and distribution advisories for the exact backported fix
• Test reset behavior under load after patching to confirm stability
• Restrict untrusted local access until patches are deployed