CVE-2024-42287: Linux qla2xxx Race Causes Kernel OOPS and Patch Guide

A subtle race in the Linux SCSI qla2xxx driver that could crash hosts during NPIV or firmware reset sequences has been publicly documented as CVE-2024-42287; upstream maintainers have issued a targeted fix (complete command handling while holding the driver lock) and major distributions have rolled the correction into patched kernel packages.

Background​

The qla2xxx family provides the Linux kernel driver for QLogic Fibre Channel (FC) host bus adapters and related SCSI paths used by storage servers, SAN-connected hosts, and NVMe-over-FC setups. Because these drivers interact with low-level DMA, scatter/gather lists and complex abort/recovery paths, even small ordering mistakes in abort or unload code can produce kernel-level faults. CVE-2024-42287 arose from exactly that class of bug: a command completion performed in the driver unload/abort path outside of the spinlock that protects the command state, introducing a race that led to a NULL pointer dereference in certain reset/NPIV flows.
The crash signatures supplied in public advisories show the fault surfacing inside DMA unmap code (dma_direct_unmap_sg), with the call trace pointing back into qla2xxx abort/completion routines. The behavior reported by maintainers and distributors is consistent: an early completion performed outside the lock allowed a command completion to occur concurrently from multiple paths, resulting in pointers being dereferenced after they had been freed or otherwise invalidated — an availability-impacting kernel OOPS.

---

What went wrong — technical root cause​

At a high level the bug is a classic lock-order/race problem in an abort/unload path:

• The driver’s code attempted to avoid triggering a WARN_ON by moving a call to the command completion callback (sp->done()) outside of the associated spinlock during driver unload/abort processing.
• That change removed a synchronization boundary that previously guaranteed the command would not be completed concurrently by another path.
• As a result, two completion paths could run in parallel: one executing the completion (and possibly freeing or unmapping associated resources) while the other still assumed those resources were valid.
• The kernel crash traces show the memory-reference fault occurring during DMA unmap work (dma_direct_unmap_sg), a clear symptom of a resource having been freed or nulled out earlier than intended.

This is not a straightforward buffer overflow or user-controlled memory corruption; it’s a concurrency hazard in kernel-space control flow. The practical consequence is deterministic instability — a kernel thread oops that can cascade into broader availability problems, from service disruption to forced reboots, depending on workload and recovery behavior.

---

Scope, affected kernels, and severity​

Public CVE records and distro advisories map the upstream fix into multiple kernel stable streams and list affected ranges; the Common Vulnerability Scoring and vendor assessments converge on a local attack vector with primary impact to availability. NVD and several distribution trackers list the flaw as medium-severity overall, with CVSS v3-ish metrics that reflect Local attack vector and an Availability-only impact (e.g., base scores often shown around the mid‑4 to mid‑5 range depending on vendor enrichment).
Affected kernel branches reported in trackers and NVD CPE mappings include a variety of 5.x and 6.x stable trees where the vulnerable qla2xxx code was present prior to the upstream corrections. Because distributors backport patches differently across their stable kernels, the exact list of vulnerable package versions is vendor-specific — check your distribution advisory for precise package names and fixed versions.
Practical exposure is determined by three things:

• Whether the host’s kernel tree included the vulnerable qla2xxx code (most mainstream kernels do unless explicitly removed).
• Whether the host actually uses QLogic FC adapters (qla2xxx module present or built-in).
• Whether the specific abort/reset/NPIV conditions are reachable in the deployed workload and configuration.

---

Upstream fix and what changed​

The upstream remedy is surgical: restore the synchronization boundary by completing the command within the spinlock during the unload/abort path so that the completion path cannot race with other completion or free/unmap code paths. In short, the driver must not call sp->done() in that unload path while the structure it references is unprotected. Kernel stable-tree commits implement this by moving the completion call back inside the lock or by otherwise ensuring the state machine cannot be observed by two concurrent completers. Public trackers list the merged stable commits and reference kernel stable backports used by vendors.
Distribution and vendor backports vary — vendors like Ubuntu, Oracle, Amazon Linux and SUSE incorporated the upstream patching into their kernel updates and, where supported, into livepatch channels or UEK/enterprise kernel trees. Administrators should prefer vendor-supplied packages rather than attempting ad-hoc local edits to the driver.

---

Vendor advisories and timelines​

Major downstream vendors and cloud distributions published advisories mapping the upstream correction to package updates:

• Ubuntu published a security advisory for CVE-2024-42287 with package-level fixes for affected kernel series and a medium priority assessment.
• Oracle’s Linux/CVE repository lists the CVE with platform errata and backported fixes into their UEK kernels.
• AWS / Amazon Linux ALAS entries index the CVE alongside related qla2xxx fixes delivered via ALAS kernel errata.
• NVD, OSV and other trackers consolidate the upstream commits and vendor advisories to provide the cross-reference administrators need to find their vendor-specific package.

Microsoft’s Security Response Center (MSRC) also includes product-level attestation language for Linux kernel CVEs; for similar kernel CVEs the MSRC text confirms that Microsoft’s Azure Linux images include the implicated upstream code and are therefore potentially affected — an important operational pointer for Azure customers to prioritize patching. Treat vendor attestation statements as an inventory and remediation cue, but remember they are product-scoped: absence of an attestation for another vendor artifact is not proof that artifact is unaffected.

---

Exploitability — what attackers can (and cannot) do​

CVE-2024-42287 is not a remote, unauthenticated code-execution bug. Publicly available technical notes from the kernel team and distributors indicate:

• Attack vector: Local — an unprivileged or low-privileged local actor (or an unwitting process running on the host) would need to trigger the problematic abort/NPIV/reset sequence.
• Impact: Availability — the typical result is a kernel OOPS or panic (denial-of-service). There is no public evidence the defect directly leads to confidentiality or integrity compromise in the wild.

At disclosure, trackers and vendor notes did not record active exploitation campaigns or public exploit code; nevertheless, reproducible kernel crashes are a real operational liability in multi-tenant and high-availability environments. Attackers seeking to disrupt services (DoS) can find such a weakness useful if they possess local access or can induce the driver code path via legitimate I/O patterns on affected hardware.

---

Detection and forensic indicators​

Operators should treat detection as two parts: (A) identify where qla2xxx is present, and (B) spot the crash indicators in logs and telemetry.
Identification (inventory)

• Check whether the qla2xxx module is present or in use:
• modinfo qla2xxx (lists version and build info) or lsmod | grep qla2xxx
• lspci -k to show which kernel module is bound to FC HBA devices
• Record uname -a and distribution package versions; cross-reference vendor advisories to see if your kernel package is one of the patched ones.

Crash indicators and logs

• Look for OOPS / stack traces in dmesg or journalctl that reference dma_direct_unmap_sg, qla2xxx_qpair_sp_free_dma, qla2xxx_qpair_sp_compl or __qla2x00_abort_all_cmds — these names appear in the published call traces tied to the vulnerability.
• Watch for repeated NPIV or firmware-reset events tied to the qla2xxx driver on hosts that have experienced unexplained reboots or storage-stack instability.
• If you have kernel crash collectors or telemetry (kdump/abrscan/log aggregation), search historical traces for the indicated symbols and timestamps around incidents of service disruption.

Practical detection recipe (short)

• Inventory hosts that have QLogic HBAs and kernel packages matching affected trees.
• Collect dmesg/kernel logs and grep for qla2xxx and dma_direct_unmap_sg occurrences.
• Cross-reference timestamps of OOPS with storage firmware events and SAN topology operations (NPIV sessions, vport deletes).

---

Remediation and mitigation — step-by-step​

The single best remediation is to install vendor-supplied kernel updates that include the upstream fix and then reboot into the patched kernel. If immediate reboots are impossible, use compensating controls until you can schedule maintenance.

• Inventory and prioritize: Identify hosts with QLogic HBAs and running kernels that appear in your vendor’s affected list. Use modinfo, lspci and package managers to compile the list.
• Consult vendor advisories: Look up the exact fixed package names and versions for your distribution (Ubuntu, Oracle Linux, SUSE, Debian, Amazon Linux, etc.). These advisories will specify whether the fix was backported and whether a livepatch is available.
• Patch and reboot: Apply the vendor kernel update and reboot hosts in a controlled maintenance window. Test in staging where possible to verify storage and FC firmware compatibility.
• Temporary mitigations: If you cannot reboot immediately:
• Avoid workloads that provoke NPIV, vport deletions or firmware/reset operations on affected hosts.
• If you run in a multi-tenant or cloud environment, restrict operations that grant local access to untrusted users.
• Consider blacklisting qla2xxx only if the host does not rely on QLogic adapters — this is disruptive for storage hosts and not recommended for servers that need those devices.
• Validate fix: After patching, reproduce the pre-patch reproduction case in a staging environment (if you had one) or monitor for absence of the previous OOPS tracelines and for stable behavior across NPIV/reset operations.

---

Operational guidance for storage teams​

Because qla2xxx touches SAN and storage subsystems, coordinate with your storage and firmware teams before applying kernel updates:

• Confirm HBA firmware compatibility with the updated kernel and vendor driver iterations.
• Test in a maintenance window with representative SAN workloads, including NPIV and failover operations.
• Where possible, apply patches to a small pilot group of hosts, validate, then roll to production in staged waves.
• Maintain current backups and ensure your runbooks include steps to recover a host that fails boot after kernel update (for example, fallback boot entries).

---

What to watch for next and verification tips​

• Cross-reference your patched package versions against the vendor advisory lists; distributors occasionally issue follow-up fixes for related qla2xxx issues, so keep an eye on follow-up CVEs in the same driver family.
• Use kernel dmesg aggregation in your observability stack to track any reappearance of the stack trace symbols after rolling patches.
• If you operate on Azure or consume Microsoft-published Linux images, treat MSRC product attestations as an immediate cue to inspect your Azure Linux images and patch them according to Microsoft’s guidance; MSRC’s attestation indicates Azure Linux artifacts were identified as including the implicated upstream code at the time of publication.

---

Risk analysis — strengths of the response, and remaining concerns​

Strengths

• The upstream fix is narrow and conservative: it restores proper synchronization rather than applying broad structural changes, which reduces regression risk.
• Major distributions integrated the fix and backported it into multiple stable kernels, making remediation available through normal vendor channels.
• The vulnerability’s impact is well-scoped to availability; there is no public evidence of escalation to remote code execution or confidentiality breaches tied to this specific defect.

Remaining concerns and operational risks

• The practical exposure surface depends on build-time and runtime configuration and on actual use of QLogic hardware; some fleets may be unaware they carry the vulnerable driver if inventories are incomplete.
• Kernel-level availability bugs are inherently disruptive in multi-tenant and high-availability environments. Even without active exploit code, the ability for a non-privileged actor or an unintended workload to cause repeated OOPS events is an unacceptable operational risk for many data centers.
• Vendor backporting creates a fragmentation risk: different hosts may receive different backport semantics, so a one-size-fits-all detection rule can miss divergent builds. Always validate against the vendor advisory for the specific package and kernel build in use.

Cautionary note: While public advisories and trackers provide excellent guidance, some granular claims (for instance, exact kernel commit hashes present in a given vendor package) should be validated by comparing the vendor package’s changelog and the upstream commit; where that detail matters, fetch the vendor patch or the package diff and verify the presence of the commit. If you cannot verify binary-level backports, prefer redeploying a vendor-marked fixed kernel package or rebuilding from a known-good upstream tree.

---

Closing summary and recommended action list​

CVE-2024-42287 is a concurrency defect in the Linux kernel qla2xxx SCSI driver that can produce a kernel NULL pointer dereference and consequent host instability during NPIV/firmware reset/abort flows. The fix is available upstream and has been incorporated into vendor kernel updates; the flaw is local in attack vector and primarily impacts availability. Administrators running QLogic HBA-equipped hosts should:

• Immediately inventory systems for qla2xxx usage and identify affected kernel/package versions.
• Consult the relevant vendor advisory and install the fixed kernel package or livepatch where available.
• Reboot into the patched kernel during a planned maintenance window and validate absence of the prior OOPS traces.
• Coordinate with storage and firmware teams to validate HBA firmware compatibility and stable NPIV/reset behavior post‑patch.
• Continue monitoring dmesg/journal and kernel crash telemetry for any regression or related qla2xxx anomalies.

Acting on these steps will resolve the race condition documented in CVE-2024-42287 and restore the synchronization guarantees the driver needs to avoid command-completion races that can destabilize storage hosts.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center