CVE-2025-71235: Linux Kernel QLA2XXX Driver DOS Vulnerability

CVE-2025-71235 Overview

A race condition vulnerability has been identified in the Linux kernel's qla2xxx SCSI driver that can cause system crashes during module unload operations. The vulnerability occurs when a module unload is initiated while a fabric scan is still in progress, leading to memory management issues in interrupt context.

Critical Impact

System crash and denial of service can occur when the qla2xxx driver module is unloaded while device discovery or fabric scanning operations are active.

Affected Products

• Linux Kernel with qla2xxx SCSI driver
• QLogic Fibre Channel Host Bus Adapters (HBAs)
• Systems running qla2xxx kernel module

Discovery Timeline

• 2026-02-18 - CVE-2025-71235 published to NVD
• 2026-02-19 - Last updated in NVD database

Technical Details for CVE-2025-71235

Vulnerability Analysis

This vulnerability is a race condition in the Linux kernel's qla2xxx SCSI driver that manifests during module unload operations. When a fabric scan or device discovery is in progress and an administrator initiates a module unload, the driver sets an UNLOADING flag. However, asynchronous interrupt handlers may still be processing responses from ongoing operations.

The core issue stems from attempting to free DMA-allocated memory (dma_free_attrs) within interrupt context. When the interrupt handler receives a response and attempts to schedule a work queue item, it checks the UNLOADING flag. If the flag is set, the work item allocation is bypassed, but the previously mapped DMA memory must still be freed. This results in calling memory deallocation functions from interrupt context, which is prohibited and causes a kernel panic.

The call trace reveals the crash path through qla24xx_sp_unmap being invoked during interrupt handling via qla24xx_msix_rsp_q, demonstrating the improper context for memory operations.

Root Cause

The root cause is a lack of synchronization between the module unload procedure and ongoing asynchronous fabric scan operations. The driver fails to ensure that all in-flight operations complete before proceeding with resource cleanup. Specifically:

1. The UNLOADING flag is set without waiting for active scan operations to complete
2. Interrupt handlers continue processing responses after the flag is set
3. Memory deallocation occurs in interrupt context when work queue scheduling is bypassed
4. The kernel crashes due to calling sleeping functions from atomic context

Attack Vector

This vulnerability is primarily triggered through legitimate administrative operations rather than external attacks. The attack vector involves:

1. A fabric scan or device discovery operation is initiated on a QLogic HBA
2. While the scan is in progress, an administrator or automated script issues a module unload command (e.g., rmmod qla2xxx)
3. The race condition between the interrupt handler and the unload procedure triggers the crash

While this is not remotely exploitable, a local user with sufficient privileges to unload kernel modules could intentionally trigger this condition to cause a denial of service. The vulnerability could also be triggered unintentionally during maintenance operations or automated testing scenarios involving repeated load/unload cycles.

Detection Methods for CVE-2025-71235

Indicators of Compromise

• System crash or kernel panic with call traces involving qla24xx_sp_unmap and qla_async_scan_sp_done
• Kernel oops messages referencing the qla2xxx module during unload operations
• System logs showing IRQ context errors related to dma_free_attrs calls
• Repeated system reboots during HBA maintenance operations

Detection Strategies

• Monitor kernel logs (dmesg, /var/log/kern.log) for call traces involving qla2xxx module functions
• Set up crash dump analysis to capture kernel panics related to SCSI driver operations
• Implement monitoring for unexpected system reboots during planned maintenance windows
• Review automated scripts that perform module load/unload operations for timing issues

Monitoring Recommendations

• Enable kernel crash dump collection (kdump) to capture detailed information when panics occur
• Monitor system uptime and correlate unexpected restarts with storage-related operations
• Implement alerting on kernel panic conditions in enterprise monitoring systems
• Track qla2xxx module state transitions and fabric scan activities in system logs

How to Mitigate CVE-2025-71235

Immediate Actions Required

• Avoid unloading the qla2xxx module while fabric scans or device discovery operations are active
• Ensure all I/O operations to QLogic HBAs are quiesced before module unload
• Implement administrative procedures to verify scan completion before maintenance
• Consider scheduling maintenance windows with sufficient time for operations to complete

Patch Information

The Linux kernel development team has released patches to address this vulnerability by delaying module unload until fabric scan operations complete. The fix ensures proper synchronization between the unload procedure and asynchronous operations.

Multiple kernel commits have been published to stable kernel branches:

• Kernel Commit 528b2f1 Update
• Kernel Commit 7062eb0 Fix
• Kernel Commit 891f996 Security
• Kernel Commit 984dc1a Improvement
• Kernel Commit c068ebba Patch
• Kernel Commit d70f71d4 Change
• Kernel Commit d8af012f Update

Update to the latest stable kernel version that includes these patches.

Workarounds

• Before unloading the qla2xxx module, verify no fabric scans are in progress by checking /sys/class/scsi_host/ entries
• Use echo 1 > /sys/class/fc_host/host*/issue_lip to complete any pending operations before module removal
• Implement a delay or wait mechanism in administrative scripts before calling rmmod qla2xxx
• Consider using modprobe -r with appropriate dependencies to ensure clean unload

# Configuration example
# Safe module unload procedure for qla2xxx
# Check for active fabric scan operations before unloading
for host in /sys/class/fc_host/host*; do
    echo "Checking $(basename $host) scan state..."
    cat "$host/port_state"
done

# Wait for scans to complete (adjust timeout as needed)
sleep 30

# Verify no active I/O before unloading
lsof /dev/sd* 2>/dev/null | grep -q . && echo "Warning: Active I/O detected"

# Proceed with module unload
modprobe -r qla2xxx