CVE-2026-97531: scsi: qla2xxx: Skip vport under deletion in report ID acquisition
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Skip vport under deletion in report ID acquisition
qla24xxreportidacquisition() format-1 handling walks ha->vplist under vportslock, takes a vrefcount on the matching vport and calls qlaupdatehostmap() to register its port id.
A vport teardown via qla24xxvportdelete() sets VPORTDELETE, then qla24xxdisablevp() removes the vport from the hostmap btree and zeroes vha->did (RESETALPA). The vport is only unlinked from vplist later, in qla24xxdeallocatevpid(), which clears vpmap[idx] (RESETVPIDX) but does not touch hostmap. In the window in between, report ID acquisition can still find the vport on vplist and call qlaupdatehostmap(); with did already zeroed it takes the btreeinsert32() path and re-inserts the dying vport into hostmap. Nothing cleans that entry afterwards, so once scsihostput() frees the vha a later hostmap lookup dereferences freed memory.
Skip a vport that has VPORTDELETE set before taking the reference, so it is neither re-registered nor scheduled for DPC re-registration. This mirrors the existing guard in qla2x00alertallvps().
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.12.113-1Fixed in 7.2.12-1Fixed in 7.2.13-1 - Upgrade
Upgrade
debian/linux-6.12to a version that resolves this vulnerability.Fixed in 6.12.113-1~deb12u1 - Compensating control
In qla24xx_report_id_acquisition() format-1 handling, skip any vport with VPORT_DELETE set before taking its reference, so it is neither re-registered in host_map nor scheduled for DPC re-registration.
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Systems using the Linux kernel qla2xxx SCSI driver with virtual ports are exposed when a virtual port is being deleted while report ID acquisition processes the virtual-port list. The affected race involves the driver's host_map tracking for those virtual ports.
What conditions are needed to trigger the use-after-free?
A virtual-port teardown must overlap with qla24xx_report_id_acquisition() format-1 handling. The acquisition path can find the still-linked, deletion-marked virtual port after its port ID has been zeroed and reinsert it into host_map; a later lookup can then dereference it after the virtual host has been freed.
How can I tell whether the vulnerable state has occurred?
The described persistent bad state is a dying virtual port being reinserted into the qla2xxx host_map after VPORT_DELETE is set and its d_id is zeroed. The provided information does not specify a user-visible log message, diagnostic command, or reliable runtime indicator for detecting that state.