Description
In the Linux kernel, the following vulnerability has been resolved:

scsi: qla2xxx: Hold qpair lock when sending NVMe LS reject

qla_nvme_ls_reject_iocb() allocates from and advances the request ring
through __qla2x00_alloc_iocbs() (which assumes the hardware_lock is
held) and qla2x00_start_iocbs() (which advances the ring and rings the
request-in doorbell), but takes no lock itself. Two of its callers
invoke it without the producer lock held:

- qla_nvme_xmt_ls_rsp(), the NVMe-FC .xmt_ls_rsp transport callback, on
its error path, and

- qla2xxx_process_purls_pkt(), run from the purex work/DPC context.

Both use ha->base_qpair, whose qp_lock_ptr is hardware_lock, so they can
run concurrently with normal I/O submission on the base ring and corrupt
the ring producer state, leading to duplicated or dropped commands. The
third caller, qla2xxx_process_purls_iocb(), runs inside
qla24xx_process_response_queue() with the qpair lock already held and is
safe; that is also why the lock cannot be taken inside the helper itself
(it would recursively re-acquire hardware_lock on the response path).

Take qp_lock_ptr around the two unlocked callers and document the helper
as caller-locked. Both run in process context, so spin_lock_irqsave() is
used and nothing in the locked region sleeps.
Published: 2026-09-16
Score: 9.8 Critical
EPSS: < 1% Very Low
KEV: No
Impact: NVMe command corruption and duplication causing data integrity issues
Action: Immediate Patch
AI Analysis

Impact

The qla2xxx driver’s helper function allocates and advances an NVMe submission ring while assuming a hardware lock is held, but the function itself takes no lock. Two callers invoke it without acquiring the required producer lock, allowing simultaneous ring access during normal I/O submission. This race condition can corrupt the ring’s producer state, resulting in duplicated or dropped NVMe commands. The flaw is a classic lock‑mismanagement scenario, classified as CWE‑362.

Affected Systems

All Linux kernel installations that provide the qla2xxx SCSI driver, regardless of distribution. The vulnerability is present in kernel versions prior to the application of the patch referenced in the provided kernel commits.

Risk and Exploitability

The CVSS score of 9.8 marks this as critical, while the EPSS score of less than 1 percent indicates a low probability of real‑world exploitation. The bug operates in user‑level process context and requires a driver user with the ability to influence NVMe operations or a local attacker with kernel privileges. It is listed in no CISA KEV catalog and does not affect remote attacker vectors described in the CVE description. When exploited, it threatens the integrity and availability of storage traffic by potentially corrupting command streams.

Generated by OpenCVE AI on September 18, 2026 at 09:28 UTC.

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

  • Apply the kernel update that contains the qla2xxx lock fix for CVE‑2026‑89857
  • Rebuild or load a custom qla2xxx module that incorporates the patched source
  • Temporarily disable Fibre Channel/NVMe functionality if the system can tolerate reduced storage performance until the patch is applied

Generated by OpenCVE AI on September 18, 2026 at 09:28 UTC.

Tracking

Sign in to view the affected projects.

Advisories
Source ID Title
Debian DLA Debian DLA DLA-4817-1 linux-6.12 security update
Debian DSA Debian DSA DSA-6528-1 linux security update
History

Fri, 18 Sep 2026 09:45:00 +0000

Type Values Removed Values Added
Weaknesses CWE-362

Wed, 16 Sep 2026 14:45:00 +0000

Type Values Removed Values Added
Metrics cvssV3_1

{'score': 9.8, 'vector': 'CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H'}


Wed, 16 Sep 2026 10:45:00 +0000

Type Values Removed Values Added
Description In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Hold qpair lock when sending NVMe LS reject qla_nvme_ls_reject_iocb() allocates from and advances the request ring through __qla2x00_alloc_iocbs() (which assumes the hardware_lock is held) and qla2x00_start_iocbs() (which advances the ring and rings the request-in doorbell), but takes no lock itself. Two of its callers invoke it without the producer lock held: - qla_nvme_xmt_ls_rsp(), the NVMe-FC .xmt_ls_rsp transport callback, on its error path, and - qla2xxx_process_purls_pkt(), run from the purex work/DPC context. Both use ha->base_qpair, whose qp_lock_ptr is hardware_lock, so they can run concurrently with normal I/O submission on the base ring and corrupt the ring producer state, leading to duplicated or dropped commands. The third caller, qla2xxx_process_purls_iocb(), runs inside qla24xx_process_response_queue() with the qpair lock already held and is safe; that is also why the lock cannot be taken inside the helper itself (it would recursively re-acquire hardware_lock on the response path). Take qp_lock_ptr around the two unlocked callers and document the helper as caller-locked. Both run in process context, so spin_lock_irqsave() is used and nothing in the locked region sleeps.
Title scsi: qla2xxx: Hold qpair lock when sending NVMe LS reject
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-09-16T14:39:21.979Z

Reserved: 2026-09-11T19:38:34.771Z

Link: CVE-2026-89857

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-09-16T11:16:53.573

Modified: 2026-09-16T15:18:13.657

Link: CVE-2026-89857

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-09-18T09:30:06Z

Weaknesses
  • CWE-362

    Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')