Description

In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Skip vport under deletion in report ID acquisition qla24xx_report_id_acquisition() format-1 handling walks ha->vp_list under vport_slock, takes a vref_count on the matching vport and calls qla_update_host_map() to register its port id. A vport teardown via qla24xx_vport_delete() sets VPORT_DELETE, then qla24xx_disable_vp() removes the vport from the host_map btree and zeroes vha->d_id (RESET_AL_PA). The vport is only unlinked from vp_list later, in qla24xx_deallocate_vp_id(), which clears vp_map[idx] (RESET_VP_IDX) but does not touch host_map. In the window in between, report ID acquisition can still find the vport on vp_list and call qla_update_host_map(); with d_id already zeroed it takes the btree_insert32() path and re-inserts the dying vport into host_map. Nothing cleans that entry afterwards, so once scsi_host_put() frees the vha a later host_map lookup dereferences freed memory. Skip a vport that has VPORT_DELETE set before taking the reference, so it is neither re-registered nor scheduled for DPC re-registration. This mirrors the existing guard in qla2x00_alert_all_vps().

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-09-25T11:17:03.307Z",
  "pubdate": "2026-09-25T11:17:03.307Z",
  "executiveSummary": "The Linux kernel qla2xxx driver contains a use-after-free vulnerability within the vport management logic. Specifically, the race condition occurs during the teardown process of a virtual port (vport).\nThe vulnerability type is a Use-After-Free (UAF) arising from improper state validation when managing the host_map btree during report ID acquisition.\nIf a vport is in the process of deletion, it may still be present in the ha->vp_list. A race condition allows the kernel to re-insert a 'dying' vport into the host_map structure, which is subsequently freed when the underlying scsi_host is destroyed.\nThis impacts system stability and kernel memory integrity. Successful exploitation could lead to kernel panics or potential arbitrary code execution by triggering a use-after-free on a dangling pointer within the host_map.\nThe issue requires the system to be performing vport deletion operations simultaneously with report ID acquisition, necessitating local access to trigger SCSI management commands.",
  "technicalDetails": "The root cause is a race condition between the vport deletion flow, initiated by qla24xx_vport_delete(), and the report ID acquisition flow, handled by qla24xx_report_id_acquisition().\nDuring vport teardown, qla24xx_vport_delete() flags the vport with VPORT_DELETE and invokes qla24xx_disable_vp() to zero the vport's destination identifier (d_id) and remove it from the host_map. However, the vport remains on the ha->vp_list until qla24xx_deallocate_vp_id() is called later in the teardown sequence.\nIn the time window between the disablement and the final unlinking from vp_list, qla24xx_report_id_acquisition() iterates through ha->vp_list under vport_slock. It identifies the 'dying' vport, acquires a vref_count, and proceeds to call qla_update_host_map().\nBecause the d_id was previously zeroed (RESET_AL_PA), qla_update_host_map() incorrectly assumes the vport needs registration and performs a btree_insert32() into the host_map.\nThis results in the dying vport being re-inserted into the host_map. Since the vport is in a teardown state, no subsequent cleanup routine will remove this re-inserted entry. When scsi_host_put() is eventually called, the vha object is freed. However, the host_map still contains a reference to the now-freed memory.\nSubsequent access to the host_map (e.g., during further Fibre Channel operations or management lookups) results in a dereference of freed memory, causing kernel memory corruption or a system crash.\nThis vulnerability is triggered through local manipulation of Fibre Channel vports. While it requires no specific remote network exposure, an attacker with local user access capable of triggering SCSI host management commands can potentially weaponize this race condition to induce kernel instability."
}