CVE-2024-50025

What it actually does

Uninitialized work queue receives queued items due to initialization inside a conditional block in fnic_probe, causing the work item to be silently dropped and dependent Fibre Channel rediscovery operations to stall.

Why it matters to the business

Temporary fabric failures can leave storage devices undiscovered, disrupting SAN connectivity and availability on affected Linux systems; low EPSS and no KEV status indicate limited immediate external risk but kernel stability remains essential for enterprise storage.

How an attack unfolds

An attacker or environmental trigger (such as fabric disruption) causes the fnic interrupt handler to invoke queue_work before initialization completes, resulting in the work item never executing and blocking device rediscovery; no specific named threat actors have been observed exploiting this instance despite broad Linux kernel campaigns.

How to fix it

Upgrade the Linux kernel to a version containing commit 6b7836b80061bf1accc5d78b12bc086aed252388 or apply the nss package update to 3.67.0-7.el8_5 (Rocky Linux 8) or later; verify the flush_work initialization has been moved outside the if block in fnic_probe.

How to confirm the fix worked

Inspect the fnic_probe function to confirm workqueue initialization occurs unconditionally, reproduce fabric failure scenarios, and confirm the absence of workqueue.c warnings during fnic ISR handling.

Typical attack path

1. Load or reload the fnic driver
2. Trigger an interrupt or fabric event that calls fnic_wq_copy_cmpl_handler
3. Attempt to queue work to the still-uninitialized workqueue
4. Observe dropped work item and failed rediscovery of Fibre Channel devices

How to detect it

Search kernel logs and dmesg for workqueue warnings originating from fnic_wq_copy_cmpl_handler or fnic_isr_msix_wq_copy, and correlate with Fibre Channel rediscovery failures after fabric events.

• WARNING: CPU.*at.*workqueue.c.*__queue_work
• fnic_wq_copy_cmpl_handler
• fnic_isr_msix_wq_copy

What your security team should do

• Apply the referenced kernel or nss package updates across all affected systems within standard maintenance windows
• Include fnic driver changes in regression testing for storage failover
• Monitor kernel logs for __queue_work warnings referencing fnic modules
• Review downstream package dependencies for any additional updates