Messages in this thread | | | From | Zheng Hacker <> | Date | Thu, 3 Nov 2022 12:12:59 +0800 | Subject | Re: [PATCH] scsi: lpfc: fix double free bug in lpfc_bsg_write_ebuf_set |
| |
James Smart <jsmart2021@gmail.com> 于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
| |