CVE-2024-26846

What it actually does

Race condition in nvme-fc module exit path between nvme_delete_ctrl and ida_destroy allows indefinite hang in wait_for_completion during module unload.

Why it matters to the business

Kernel module unload can hang indefinitely on systems using NVMe over Fibre Channel, disrupting driver maintenance, resource cleanup, and requiring reboots in storage environments.

How an attack unfolds

An attacker or automated test triggers repeated controller deletion and module unload sequences that expose incomplete synchronization, causing the nvme_fc_exit_module path to block forever.

How to fix it

Upgrade the Linux kernel to a version containing commit 4f2c95015ec2a1899161be6c0bdaecedd5a7bfb2, which removes the flawed wait logic, adds flush_workqueue(nvme_delete_wq), and eliminates the unused nvme_fc_wq.

How to confirm the fix worked

Confirm the running kernel source contains the flush_workqueue call in nvme_fc_exit_module and lacks the original wait_for_completion synchronization around ida_destroy.

Typical attack path

1. Load nvme-fc module and establish controllers
2. Initiate concurrent deletion paths via blktests or equivalent workload
3. Trigger module unload while IDs remain unfreed
4. Observe hang due to unhandled wait_for_completion case

How to detect it

Inspect kernel logs for nvme-fc module unload stalls, workqueue flush messages, or indefinite waits in nvme_delete_ctrl paths after module removal attempts.

What your security team should do

• Apply the fixed kernel version immediately on any system exposing nvme-fc
• Validate module unload succeeds after patching
• Review storage driver usage for similar race patterns in custom builds