Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20221028050736.151185-1-zyytlz.wz@163.com> <0ce67c60-7b55-6f29-2f97-9b17c1e175c0@gmail.com>
In-Reply-To: <0ce67c60-7b55-6f29-2f97-9b17c1e175c0@gmail.com>
From:   Zheng Hacker <hackerzheng666@gmail.com>
Date:   Thu, 3 Nov 2022 12:12:59 +0800
Message-ID: <CAJedcCzvkcnkntM6h3NAV6ct36RY-bKyHichQ4ecRop7wfHuhg@mail.gmail.com>
Subject: Re: [PATCH] scsi: lpfc: fix double free bug in lpfc_bsg_write_ebuf_set
To:     James Smart <jsmart2021@gmail.com>
Cc:     Zheng Wang <zyytlz.wz@163.com>, james.smart@broadcom.com,
        dick.kennedy@broadcom.com, jejb@linux.ibm.com,
        martin.petersen@oracle.com, linux-scsi@vger.kernel.org,
        alex000young@gmail.com, security@kernel.org,
        linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

James Smart <jsmart2021@gmail.com> =E4=BA=8E2022=E5=B9=B411=E6=9C=883=E6=97=
=A5=E5=91=A8=E5=9B=9B 00:37=E5=86=99=E9=81=93=EF=BC=9A

> 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, st=
ruct bsg_job *job,
> >               lpfc_printf_log(phba, KERN_ERR, LOG_LIBDFC,
> >                               "2970 Failed to issue SLI_CONFIG ext-buff=
er "
> >                               "mailbox command, rc:x%x\n", rc);
> > -             rc =3D -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