When error occurs, it frees dmabuf in both lpfc_bsg_write_ebuf_set
and lpfc_bsg_issue_mbox.
Fix it by removing free code in lpfc_bsg_write_ebuf_set.
Reported-by: Zheng Wang <[email protected]>
Reported-by: Zhuorao Yang <[email protected]>
Fixes: 7ad20aa9d39a ("[SCSI] lpfc 8.3.24: Extend BSG infrastructure and add link diagnostics")
Signed-off-by: Zheng Wang <[email protected]>
---
drivers/scsi/lpfc/lpfc_bsg.c | 17 +++--------------
1 file changed, 3 insertions(+), 14 deletions(-)
diff --git a/drivers/scsi/lpfc/lpfc_bsg.c b/drivers/scsi/lpfc/lpfc_bsg.c
index ac0c7ccf2eae..7362d9c1a50b 100644
--- a/drivers/scsi/lpfc/lpfc_bsg.c
+++ b/drivers/scsi/lpfc/lpfc_bsg.c
@@ -4439,15 +4439,13 @@ lpfc_bsg_write_ebuf_set(struct lpfc_hba *phba, struct bsg_job *job,
dd_data = kmalloc(sizeof(struct bsg_job_data), GFP_KERNEL);
if (!dd_data) {
- rc = -ENOMEM;
- goto job_error;
+ return -ENOMEM;
}
/* mailbox command structure for base driver */
pmboxq = mempool_alloc(phba->mbox_mem_pool, GFP_KERNEL);
if (!pmboxq) {
- rc = -ENOMEM;
- goto job_error;
+ return -ENOMEM;
}
memset(pmboxq, 0, sizeof(LPFC_MBOXQ_t));
pbuf = (uint8_t *)phba->mbox_ext_buf_ctx.mbx_dmabuf->virt;
@@ -4480,8 +4478,7 @@ lpfc_bsg_write_ebuf_set(struct lpfc_hba *phba, struct bsg_job *job,
lpfc_printf_log(phba, KERN_ERR, LOG_LIBDFC,
"2970 Failed to issue SLI_CONFIG ext-buffer "
"mailbox command, rc:x%x\n", rc);
- rc = -EPIPE;
- goto job_error;
+ return -EPIPE;
}
/* wait for additional external buffers */
@@ -4489,14 +4486,6 @@ lpfc_bsg_write_ebuf_set(struct lpfc_hba *phba, struct bsg_job *job,
bsg_job_done(job, bsg_reply->result,
bsg_reply->reply_payload_rcv_len);
return SLI_CONFIG_HANDLED;
-
-job_error:
- if (pmboxq)
- mempool_free(pmboxq, phba->mbox_mem_pool);
- lpfc_bsg_dma_page_free(phba, dmabuf);
- kfree(dd_data);
-
- return rc;
}
/**
--
2.25.1
On 10/27/2022 10:07 PM, Zheng Wang wrote:
> When error occurs, it frees dmabuf in both lpfc_bsg_write_ebuf_set
> and lpfc_bsg_issue_mbox.
>
> Fix it by removing free code in lpfc_bsg_write_ebuf_set.
>
> Reported-by: Zheng Wang <[email protected]>
> Reported-by: Zhuorao Yang <[email protected]>
>
> Fixes: 7ad20aa9d39a ("[SCSI] lpfc 8.3.24: Extend BSG infrastructure and add link diagnostics")
>
> Signed-off-by: Zheng Wang <[email protected]>
> ---
> drivers/scsi/lpfc/lpfc_bsg.c | 17 +++--------------
> 1 file changed, 3 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/scsi/lpfc/lpfc_bsg.c b/drivers/scsi/lpfc/lpfc_bsg.c
> index ac0c7ccf2eae..7362d9c1a50b 100644
> --- a/drivers/scsi/lpfc/lpfc_bsg.c
> +++ b/drivers/scsi/lpfc/lpfc_bsg.c
> @@ -4439,15 +4439,13 @@ lpfc_bsg_write_ebuf_set(struct lpfc_hba *phba, struct bsg_job *job,
>
> dd_data = kmalloc(sizeof(struct bsg_job_data), GFP_KERNEL);
> if (!dd_data) {
> - rc = -ENOMEM;
> - goto job_error;
> + return -ENOMEM;
> }
>
> /* mailbox command structure for base driver */
> pmboxq = mempool_alloc(phba->mbox_mem_pool, GFP_KERNEL);
> if (!pmboxq) {
> - rc = -ENOMEM;
> - goto job_error;
> + return -ENOMEM;
> }
> memset(pmboxq, 0, sizeof(LPFC_MBOXQ_t));
> pbuf = (uint8_t *)phba->mbox_ext_buf_ctx.mbx_dmabuf->virt;
Minimally, just looking at this one snippet, by returning after the
mempool_alloc() failure, we are leaking the dd_data memory just allocated.
> @@ -4480,8 +4478,7 @@ lpfc_bsg_write_ebuf_set(struct lpfc_hba *phba, struct bsg_job *job,
> lpfc_printf_log(phba, KERN_ERR, LOG_LIBDFC,
> "2970 Failed to issue SLI_CONFIG ext-buffer "
> "mailbox command, rc:x%x\n", rc);
> - rc = -EPIPE;
> - goto job_error;
> + return -EPIPE;
and this leaks both the dd_data and pmboxq memory.
> }
>
> /* wait for additional external buffers */
> @@ -4489,14 +4486,6 @@ lpfc_bsg_write_ebuf_set(struct lpfc_hba *phba, struct bsg_job *job,
> bsg_job_done(job, bsg_reply->result,
> bsg_reply->reply_payload_rcv_len);
> return SLI_CONFIG_HANDLED;
> -
> -job_error:
> - if (pmboxq)
> - mempool_free(pmboxq, phba->mbox_mem_pool);
> - lpfc_bsg_dma_page_free(phba, dmabuf);
> - kfree(dd_data);
> -
> - return rc;
> }
>
> /**
all of these errors should cause:
lpfc_bsg_write_ebuf_set() to return -Exxx
causing lpfc_bsg_handle_sli_cfg_ebuf() to return -Exxx
causing lpfc_bsg_handle_sli_cfg_ext() to return -Exxx
which causes lpfc_bsg_issue_mbox() to jump to job_done
I understand the argument is that issue_mbox deletes them, but....
job_done:
checks/frees pmboxq is allocated after the jump so it will be NULL
frees dmabuf - which was allocated prior to the jump; is freed
in freedlpfc_bsg_handle_sli_cfg_ebuf() but only in a block
that returns SLI_CONFIG_HANDLED, which is not the block that
invokes lpfc_bsg_write_ebuf_set. So it's valid to delete.
Note: there's a special case for SLI_CONFIG_HANDLED which skips
over these deletes so it's ok.
frees dd_data - which is allocated after the jump so it too will
be NULL
So - the code is fine. The SLI_CONFIG_HANDLED is a little weird, but
the logic is fine. If the patch were added it would leak memory.
I take it this was identified by some tool ?
-- james
James Smart <[email protected]> 于2022年11月3日周四 00:37写道：
> Minimally, just looking at this one snippet, by returning after the
> mempool_alloc() failure, we are leaking the dd_data memory just allocated.
>
Yes, this is a bad patch.
> > @@ -4480,8 +4478,7 @@ lpfc_bsg_write_ebuf_set(struct lpfc_hba *phba, struct bsg_job *job,
> > lpfc_printf_log(phba, KERN_ERR, LOG_LIBDFC,
> > "2970 Failed to issue SLI_CONFIG ext-buffer "
> > "mailbox command, rc:x%x\n", rc);
> > - rc = -EPIPE;
> > - goto job_error;
> > + return -EPIPE;
>
> and this leaks both the dd_data and pmboxq memory.
So Here it is.
>
> all of these errors should cause:
> lpfc_bsg_write_ebuf_set() to return -Exxx
> causing lpfc_bsg_handle_sli_cfg_ebuf() to return -Exxx
> causing lpfc_bsg_handle_sli_cfg_ext() to return -Exxx
> which causes lpfc_bsg_issue_mbox() to jump to job_done
>
Hi James! Really apprecaite for your reply. I was not sure if it it a
really issue. Sorry for the bad patch.
> I understand the argument is that issue_mbox deletes them, but....
>
> job_done:
> checks/frees pmboxq is allocated after the jump so it will be NULL
> frees dmabuf - which was allocated prior to the jump; is freed
> in freedlpfc_bsg_handle_sli_cfg_ebuf() but only in a block
> that returns SLI_CONFIG_HANDLED, which is not the block that
> invokes lpfc_bsg_write_ebuf_set. So it's valid to delete.
> Note: there's a special case for SLI_CONFIG_HANDLED which skips
> over these deletes so it's ok.
> frees dd_data - which is allocated after the jump so it too will
> be NULL
I understood your point. Here is a call chain :
lpfc_bsg_issue_mbox->lpfc_bsg_handle_sli_cfg_ext->lpfc_bsg_handle_sli_cfg_ebuf->lpfc_bsg_write_ebuf_set->lpfc_bsg_dma_page_free->kfree(dmabuf)
It leads to another kfree in lpfc_bsg_mbox_cmd :
job_done:
/* common exit for error or job completed inline */
if (pmboxq)
mempool_free(pmboxq, phba->mbox_mem_pool);
[7] lpfc_bsg_dma_page_free(phba, dmabuf);
kfree(dd_data);
So the key point is whether phba->mbox_ext_buf_ctx.mboxType can be
mbox_wr. If not, just as you illustrated, all is fine.
It will get into SLI_CONFIG_HANDLED path and handle dmabuf as expected.
But if not, it will have a chance to trigger a double-free bug. I
found phda is assigned in lpfc_bsg_mbox_cmd. But I am still not sure
about its value.
Appreciate if you can help me to understand more about the key condition :)
> So - the code is fine. The SLI_CONFIG_HANDLED is a little weird, but
> the logic is fine. If the patch were added it would leak memory.
>
> I take it this was identified by some tool ?
>
Yes, I found it using Codeql. I didn't have a poc to verify.
Best Regards,
Zheng Wang