Re: [PATCH v4 31/56] scsi: qla2xxx: Add 29xx extended logio IOCB support

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] This problem wasn't introduced by this patch, but DMA memory corruption occurs due to freeing the IOCB buffer before the firmware is reset on a timeout.
--

--- Patch [31]: [PATCH v4 31/56] scsi: qla2xxx: Add 29xx extended logio IOCB support ---
commit fd255e4f21f55aa8baef081e73e914c2d628d372
Author: Nilesh Javali <njavali@marvell.com>

scsi: qla2xxx: Add 29xx extended logio IOCB support

This commit adds extended logio IOCB support for the 29xx series, which uses
a wider IOCB stride (128 bytes vs 64 bytes). It updates various logio IOCB
builder and completion functions to accept a void pointer and cast dynamically
to accommodate both layouts.

> diff --git a/drivers/scsi/qla2xxx/qla_mbx.c b/drivers/scsi/qla2xxx/qla_mbx.c
> index f9b326c020557..7dff227899a52 100644
> --- a/drivers/scsi/qla2xxx/qla_mbx.c
> +++ b/drivers/scsi/qla2xxx/qla_mbx.c
[ ... ]
> @@ -2678,7 +2680,7 @@ qla24xx_login_fabric(scsi_qla_host_t *vha, uint16_t loop_id, uint8_t domain,
>  						 */
>  	}
>  
> -	dma_pool_free(ha->s_dma_pool, lg, lg_dma);
> +	dma_pool_free(ha->s_dma_pool, lg_buf, lg_dma);

[Severity: High]
This is a pre-existing issue, but could this lead to DMA memory corruption if
the command times out?

If qla2x00_issue_iocb_timeout() times out, it schedules an asynchronous DPC
reset and returns, causing lg_buf to be immediately freed back to the DMA
pool here in qla24xx_login_fabric().

If the firmware is merely slow and completes the command before the adapter
reset fully finishes, won't it write the completion status to the physical
address (lg_dma) of this freed buffer?

This could corrupt whatever new allocation is currently using that DMA memory.

>  
>  	return rval;
>  }
[ ... ]
> @@ -2898,7 +2903,7 @@ qla24xx_fabric_logout(scsi_qla_host_t *vha, uint16_t loop_id, uint8_t domain,
>  		    "Done %s.\n", __func__);
>  	}
>  
> -	dma_pool_free(ha->s_dma_pool, lg, lg_dma);
> +	dma_pool_free(ha->s_dma_pool, lg_buf, lg_dma);

[Severity: High]
This is the same pre-existing issue, but in qla24xx_fabric_logout().

Does freeing lg_buf here after a timeout expose the system to use-after-free
DMA corruption if the hardware writes to lg_dma before the asynchronous reset
completes?

>  
>  	return rval;
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260714095353.289460-1-njavali@marvell.com?part=31