Descripción
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: scsi: qla2xxx: Mantener el bloqueo de qpair al enviar un rechazo NVMe LS qla_nvme_ls_reject_iocb() asigna desde el anillo de solicitudes y lo hace avanzar mediante __qla2x00_alloc_iocbs() (que asume que se mantiene hardware_lock) y qla2x00_start_iocbs() (que hace avanzar el anillo y activa el doorbell de request-in), pero no toma ningún bloqueo por sí misma. Dos de sus llamadores la invocan sin mantener el bloqueo del productor: - qla_nvme_xmt_ls_rsp(), la función de devolución de llamada de transporte .xmt_ls_rsp de NVMe-FC, en su ruta de error, y - qla2xxx_process_purls_pkt(), ejecutada desde el contexto de trabajo purex/DPC. Ambas usan ha->base_qpair, cuyo qp_lock_ptr es hardware_lock, por lo que pueden ejecutarse de forma concurrente con el envío normal de E/S en el anillo base y corromper el estado del productor del anillo, lo que provoca comandos duplicados o descartados. El tercer llamador, qla2xxx_process_purls_iocb(), se ejecuta dentro de qla24xx_process_response_queue() con el bloqueo de qpair ya tomado y es seguro; por eso tampoco se puede tomar el bloqueo dentro de la propia función auxiliar (volvería a adquirir recursivamente hardware_lock en la ruta de respuesta). Se toma qp_lock_ptr en torno a los dos llamadores sin bloqueo y se documenta que la función auxiliar requiere que el llamador mantenga el bloqueo. Ambos se ejecutan en contexto de proceso, por lo que se usa spin_lock_irqsave() y nada en la región bloqueada entra en suspensión.
Qué hacer
Revisa si usas el producto afectado y en qué versión, y aplica la actualización o la mitigación que indique el aviso del fabricante. CISA no ha confirmado que se esté explotando; si eso cambia, esta ficha pasa a «explotada» y te avisamos en el boletín.
Versiones afectadas
- Linux Afectadas: 875386b98857822b77ac7f95bdf367b70af5b78c y anteriores a 7eb618877503edbf17aa65e357a81bda1fc8f163 · 875386b98857822b77ac7f95bdf367b70af5b78c y anteriores a b3a362466db6b8ec47cc537ac641ac197fa69b5d · 875386b98857822b77ac7f95bdf367b70af5b78c y anteriores a 11834e5773e20fd3742d7eb900876e66b9e7d029 · 875386b98857822b77ac7f95bdf367b70af5b78c y anteriores a b02ff132017b28222187ebcf95ce7f4cb576cd36 · 875386b98857822b77ac7f95bdf367b70af5b78c y anteriores a f743488e4a203049f27ec5d8cd0caccc483af01e
- Linux Afectadas: 6.6 No afectadas: 6.6.157 · 6.12.110 · 6.18.51 · 7.2.5 · 7.3
Según el registro de la vulnerabilidad en CVE.org, tal como lo publicó el fabricante. Confirma tu versión exacta en el aviso del fabricante.
Referencias
- Referencia en git.kernel.orggit.kernel.org/stable/c/7eb618877503edbf17aa65e357a81bda1fc8f163
- Referencia en git.kernel.orggit.kernel.org/stable/c/b3a362466db6b8ec47cc537ac641ac197fa69b5d
- Referencia en git.kernel.orggit.kernel.org/stable/c/11834e5773e20fd3742d7eb900876e66b9e7d029
- Referencia en git.kernel.orggit.kernel.org/stable/c/b02ff132017b28222187ebcf95ce7f4cb576cd36
- Referencia en git.kernel.orggit.kernel.org/stable/c/f743488e4a203049f27ec5d8cd0caccc483af01e
Ver el texto original en inglés (CVE.org)
scsi: qla2xxx: Hold qpair lock when sending NVMe LS reject
In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Hold qpair lock when sending NVMe LS reject qla_nvme_ls_reject_iocb() allocates from and advances the request ring through __qla2x00_alloc_iocbs() (which assumes the hardware_lock is held) and qla2x00_start_iocbs() (which advances the ring and rings the request-in doorbell), but takes no lock itself. Two of its callers invoke it without the producer lock held: - qla_nvme_xmt_ls_rsp(), the NVMe-FC .xmt_ls_rsp transport callback, on its error path, and - qla2xxx_process_purls_pkt(), run from the purex work/DPC context. Both use ha->base_qpair, whose qp_lock_ptr is hardware_lock, so they can run concurrently with normal I/O submission on the base ring and corrupt the ring producer state, leading to duplicated or dropped commands. The third caller, qla2xxx_process_purls_iocb(), runs inside qla24xx_process_response_queue() with the qpair lock already held and is safe; that is also why the lock cannot be taken inside the helper itself (it would recursively re-acquire hardware_lock on the response path). Take qp_lock_ptr around the two unlocked callers and document the helper as caller-locked. Both run in process context, so spin_lock_irqsave() is used and nothing in the locked region sleeps.