GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel qla2xxx: commands leak after chip reset, and racing unmaps hit a BUG_ON

CVSS 9.8CVE-2025-68745Kernel, userspace & hypervisorcurated

Impact

A pair of earlier qla2xxx fixes left two defects in the abort-all-commands path. After a chip reset, commands already handed to firmware are never completed or freed because the firmware will not answer them, so they hang and their resources leak; separately, two CPUs racing into qlt_unmap_sg() hit BUG_ON(!valid_dma_direction(dir)) in dma_unmap_sg_attrs(), which is an immediate kernel panic. This is an availability problem on storage-attached nodes: a chip reset is a routine recovery event, not an attack, and the aftermath is either stuck I/O or a crashed node that must be rebooted to restore its Fibre Channel paths. The fix reverts the DMA-unmap change and partially reverts the offline-port handling in __qla2x00_abort_all_cmds. Note this is a distinct bug from CVE-2025-68741 in the same driver, with a different code path and fix.

Who can reach it

No attacker needed in the usual sense - the trigger is a qla2xxx chip reset or host reset on a node running the FC target/initiator code, after which cleanup goes wrong. Fabric instability or a flapping port is enough. Not reachable from a tenant GPU pod.

What to do

Take the stable-kernel fix (commits below) and reboot affected nodes; the change is in driver cleanup code with no runtime toggle. Drain the node first, since rebooting a host with mounted FC LUNs takes its jobs with it. If a node is already in the stuck-command state, a reboot is the way out.

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.