Linux qla2xxx: NULL dma_free and mismatched bitmap locking in multiqueue queue teardown

UnscoredCVE-2026-97537Kernel, userspace & hypervisorcurated

Impact

Two distinct defects in qla25xx_free_req_que()/qla25xx_free_rsp_que(), exposed by the queue-creation error path. First, when dma_alloc_coherent() fails the free function runs with req->ring / rsp->ring still NULL and calls dma_free_coherent() on a NULL cpu_addr, which can panic. Second, the free functions cleared req_qid_map / rsp_qid_map under vport_lock while the creators protect the same bitmaps with mq_lock, so there is no mutual exclusion; the create error path also cleared the bit and dropped mq_lock before calling free, leaving a window in which another thread allocates the same que_id and has its ha->req_q_map entry clobbered by the lockless NULL assignment. On a host using QLogic FC multiqueue this means a panic or corrupted queue mapping under concurrent queue setup. This is separate from the qla2x00_mem_alloc double free (CVE-2026-97532) - different functions, different fix. No CVSS score is given.

Who can reach it

Local and privileged: the paths run during driver queue creation and teardown. The race needs concurrent multiqueue create/free, and the NULL free needs a coherent-DMA allocation failure. No tenant or remote vector is described.

What to do

Take a stable kernel with the NULL ring guard and the mq_lock conversion (three stable commits listed) and reboot the affected FC hosts; fold it into a normal kernel maintenance window. The record names no distro fixed version.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-97537 https://git.kernel.org/stable/c/34a40e0dff940ac5eba494a69b553ea571e24873 https://git.kernel.org/stable/c/94fc0c5b45de2bf3a691619bcfd10b9a49fc647e https://git.kernel.org/stable/c/f35cb67f2092b49d7949065dd56895ed47238f22

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.