GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel qla2xxx: virtual port used after vport_slock is dropped, allowing a use-after-free

CVSS 8.1CVE-2026-89861Kernel, userspace & hypervisorcurated

Impact

In the format 1 path of qla24xx_report_id_acquisition(), the driver finds a virtual port on ha->vp_list under vport_slock, drops the lock, then keeps using the vport - calling qla_update_host_map() and setting VP_IDX_ACQUIRED, REGISTER_FC4_NEEDED and REGISTER_FDMI_NEEDED on it - without holding a reference. A concurrent qla24xx_deallocate_vp_id() can free the vport in that window, so the driver writes into freed memory. This affects NPIV deployments, which is how many operators carve one FC HBA into per-tenant or per-workload virtual ports; the corruption is in the host kernel, so the blast radius is the whole node, not one initiator.

Who can reach it

Local and indirect - driven by FC fabric events and concurrent NPIV vport creation/teardown on hosts with QLogic FC HBAs using virtual ports. No tenant-facing interface and no authentication step.

What to do

Update to a stable kernel that takes vref_count under vport_slock for the matching vport and drops it after the last use. Kernel-image fix, so it means draining and rebooting each affected node. Only hosts running qla2xxx with NPIV virtual ports are exposed; the rest can wait for a normal patch cycle.

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.