Bug 2541235 (CVE-2026-97527) - CVE-2026-97527 kernel: scsi: qla2xxx: Serialize NVMe unsol ctx list with a per-fcport lock
Summary: CVE-2026-97527 kernel: scsi: qla2xxx: Serialize NVMe unsol ctx list with a pe...
Keywords:
Status: NEW
Alias: CVE-2026-97527
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Product Security DevOps Team
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2026-09-25 11:08 UTC by OSIDB Bzimport
Modified: 2026-09-28 19:15 UTC (History)
17 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed:
Embargoed:


Attachments (Terms of Use)

Description OSIDB Bzimport 2026-09-25 11:08:35 UTC
In the Linux kernel, the following vulnerability has been resolved:

scsi: qla2xxx: Serialize NVMe unsol ctx list with a per-fcport lock

The fcport->unsol_ctx_head list is modified from several contexts without
a common lock. Entries are added in qla2xxx_process_purls_iocb() from the
response queue ISR (under the qpair qp_lock), while they are removed from
qla2xxx_process_purls_pkt() (DPC/purex worker), qla_nvme_xmt_ls_rsp()
(NVMe-FC transport callback) and qla_nvme_release_lsrsp_cmd_kref() (SRB
completion). The qpair qp_lock cannot serialize this per-fcport list since
multiqueue adapters add entries through different qpairs, so a concurrent
add and delete (or two concurrent deletes) can corrupt the list pointers.

Introduce a dedicated per-fcport spinlock, unsol_ctx_lock, initialized in
qla2x00_alloc_fcport(), and take it around every list_add_tail()/list_del()
on unsol_ctx_head. The add nests under the existing qp_lock; no delete path
takes qp_lock, so the lock order is consistent and deadlock free.


Note You need to log in before you can comment on or make changes to this bug.