qla2xxx Driver CVE-2026-97527

Requires a system running the Linux qla2xxx driver on a QLogic Fibre Channel HBA operating in NVMe-FC mode with a multiqueue adapter (entries added via different qpairs), which is the specific configuration that defeats the existing qp_lock serialization. The race is triggered by normal concurrent NVMe-FC traffic and internal timing (ISR add racing worker/transport/completion deletes), NOT by attacker-supplied network data - so exploitation is bounded to environments with QLogic FC SAN hardware and NVMe-over-FC storage, and is effectively a reliability/timing condition rather than a remotely-controllable one.

This is a classic case of a severely overstated CVSS score. The NVD vector CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H (8.8) is inconsistent with the actual defect described: a concurrency race (CWE-362) on the per-fcport unsol_ctx_head linked list inside the qla2xxx QLogic Fibre Channel HBA driver's NVMe-FC path. AV:A (adjacent-network) is implausible - this list is manipulated only by internal driver contexts (response-queue ISR, DPC/purex worker, NVMe-FC transport callback, SRB completion), not by any attacker-controlled network input; there is no evidence a remote or adjacent attacker can steer the timing. C:H/I:H are unfounded: list-pointer corruption from a concurrent add/delete yields a crash or memory corruption (availability impact), not confidentiality or integrity compromise. There is no EPSS score, no CISA KEV listing, and no public exploit - consistent with an internally-discovered robustness/hardening fix rather than a weaponizable flaw. Realistically this is a low-priority reliability bug on a niche storage subsystem, not a security priority. Conflicting signal to flag: the 'Information Disclosure' tag directly contradicts the description, which is a race leading to list corruption (no data disclosure) - verify against vendor. My independent assessment is ~5.0 (AV:L/AC:H/PR:L/C:N/I:L/A:H).

On a multiqueue QLogic FC adapter carrying NVMe-FC traffic, unsolicited LS contexts are added to fcport->unsol_ctx_head from the response-queue ISR on one qpair while other contexts concurrently remove entries; without a common lock the list pointers are corrupted, producing a kernel crash or memory corruption. Triggering requires precise timing under normal heavy NVMe-FC load rather than any crafted attacker input, and no public exploit or POC exists.