GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel qla2xxx: NVMe LS reject path advances the request ring without the qpair lock

CVSS 9.8CVE-2026-89857Kernel, userspace & hypervisorcurated

Impact

qla_nvme_ls_reject_iocb() allocates from and advances the hardware request ring, but two callers - the NVMe-FC .xmt_ls_rsp error path and the purex work context - invoked it with no lock held. Both use the base qpair whose lock is hardware_lock, so they can run alongside normal I/O submission and corrupt the ring producer state, duplicating or dropping SCSI/NVMe commands. On a storage-attached node that is silent data-path damage rather than a clean crash, which is the worse failure mode for a shared filesystem backing training checkpoints. Only nodes with QLogic FC HBAs doing NVMe-over-FC are in scope.

Who can reach it

Local and hardware-dependent: needs a QLogic HBA running NVMe-over-FC, with an LS reject on the error or purex path racing normal submission. Not tenant-reachable as described.

What to do

Update to a kernel where both callers take qp_lock_ptr around the helper, and reboot the affected FC-attached nodes. Nodes without qla2xxx NVMe-FC are unaffected. The record gives stable commits only.

References

Related entries

All Kernel, userspace & hypervisor entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.