In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Serialize NVMe…

Why it is Amber

• CVSS 8.8 high
• On your watchlist: linux kernel

References

• https://git.kernel.org/stable/c/4d8ad6bc8cc5eff1870cef00a0d611f38f8b6bd0
• https://git.kernel.org/stable/c/6c71726cdfda93ae169a75c7b1697eb870303125
• https://git.kernel.org/stable/c/76da0c43c63eb0496649e372ac64466364d0fe7d
• https://git.kernel.org/stable/c/b211d138cad86f749826d6132db6388eded992d8
• https://git.kernel.org/stable/c/c1ee12eecbab9674fb73c9e00a93fac655d5a5dc

Original description

In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Serialize NVMe unsol ctx list with a per-fcport lock The fcport->unsol_ctx_head list is modified from several contexts without a common lock. Entries are added in qla2xxx_process_purls_iocb() from the response queue ISR (under the qpair qp_lock), while they are removed from qla2xxx_process_purls_pkt() (DPC/purex worker), qla_nvme_xmt_ls_rsp() (NVMe-FC transport callback) and qla_nvme_release_lsrsp_cmd_kref() (SRB completion). The qpair qp_lock cannot serialize this per-fcport list since multiqueue adapters add entries through different qpairs, so a concurrent add and delete (or two concurrent deletes) can corrupt the list pointers. Introduce a dedicated per-fcport spinlock, unsol_ctx_lock, initialized in qla2x00_alloc_fcport(), and take it around every list_add_tail()/list_del() on unsol_ctx_head. The add nests under the existing qp_lock; no delete path takes qp_lock, so the lock order is consistent and deadlock free.