GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel qla2xxx: MSI-X vector count truncates to zero and the driver dereferences ZERO_SIZE_PTR

CVSS 8.4CVE-2026-89856Kernel, userspace & hypervisorcurated

Impact

A QLogic Fibre Channel HBA that advertises 257 MSI-X vectors (or exactly 1) makes the driver derive a queue count of 0, because the u16 vector count is stored into a u8. qla2x00_alloc_queues() then allocates a zero-sized array, gets ZERO_SIZE_PTR back, passes the non-NULL check, and writes through it - memory corruption or a kernel panic at driver probe. In target mode a further decrement underflows 0 to 255. On a GPU node this is a boot-time or hot-plug-time crash of the storage path, and the commit message explicitly names a misconfigured or malicious hot-plugged device as a trigger, so the input is not purely trusted. Fleets that boot from FC SAN lose the node until the adapter is replaced or the kernel is patched.

Who can reach it

Local - requires a QLogic FC HBA present, or the ability to hot-plug/emulate one, whose MSI-X capability reports a pathological vector count. Not reachable from a tenant workload on a node with normal, correctly configured adapters. No network authentication is involved.

What to do

Update to a stable kernel containing qla_calc_queue_count(), which clamps the derived value into [1, QLA_MAX_QUEUES - 1], and guards the target-mode decrement. The fix is in the kernel image, so it takes a node drain and reboot; there is no module-reload path that avoids rebooting a node booted from the affected HBA. Nodes with no QLogic FC adapter are not affected and can be scheduled in a normal 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.