GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel qla2xxx: NPIV virtual-port index above 128 writes past the VP control IOCB bitmap

UnscoredCVE-2026-97535Kernel, userspace & hypervisorcurated

Impact

The VP control IOCB selects its target virtual port by setting one bit in vp_idx_map, a fixed 16-byte (128-bit) array. qla25xx_ctrlvp_iocb() computed the byte index as (vp_index - 1) / 8 and wrote it without checking the array bound, while qla24xx_control_vp() only rejected vp_index >= max_npiv_vports - a value taken from firmware that can legitimately be 191 or 255. A vp_index above 128 therefore writes up to 16 bytes past the bitmap, corrupting the trailing IOCB fields or, on the 64-byte layout, the adjacent request-ring slot. The commit is explicit that adapters reporting the usual 63 or 127 NPIV vports are unaffected, so for most fleets this is a latent bug conditional on firmware that advertises a large NPIV limit.

Who can reach it

Local privileged configuration of NPIV virtual ports on an HBA whose firmware reports more than 128 NPIV vports - host root or the storage provisioning agent. Not tenant reachable and not triggered from the fabric.

What to do

Run a kernel with the vp_index rejection in qla24xx_control_vp() and the ARRAY_SIZE() guard in qla25xx_ctrlvp_iocb(); four stable backports are linked in the record. That is a drain and reboot per affected node. Before scheduling anything, check what max_npiv_vports your HBA firmware actually reports - at 63 or 127 you are not exposed and this can ride along with your next routine kernel update.

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.