[PATCH] scsi: lpfc: ensure els_wq is being checked before destroying it

[Colin King]

From: Colin Ian King 

I believe there is a typo on the wq destroy of els_wq, currently
the driver is checking if els_cq is not null and I think this
should be a check on els_wq instead.

Detected by CoverityScan, CID#1411629 ("Copy-paste error")

Signed-off-by: Colin Ian King 
---
 drivers/scsi/lpfc/lpfc_init.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/lpfc/lpfc_init.c b/drivers/scsi/lpfc/lpfc_init.c
index 90ae354a9c45..c925bbe9b35d 100644
--- a/drivers/scsi/lpfc/lpfc_init.c
+++ b/drivers/scsi/lpfc/lpfc_init.c
@@ -8847,7 +8847,7 @@ lpfc_sli4_queue_unset(struct lpfc_hba *phba)
lpfc_wq_destroy(phba, phba->sli4_hba.nvmels_wq);
 
/* Unset ELS work queue */
-   if (phba->sli4_hba.els_cq)
+   if (phba->sli4_hba.els_wq)
lpfc_wq_destroy(phba, phba->sli4_hba.els_wq);
 
/* Unset unsolicited receive queue */
-- 
2.11.0

Re: [PATCH] scsi: qedf: Avoid reading past end of buffer

[Chad Dupuis]

On Fri, 5 May 2017, 7:10pm, Kees Cook wrote:

> On Fri, May 5, 2017 at 4:01 PM, Bart Van Assche
>  wrote:
> > On Fri, 2017-05-05 at 15:42 -0700, Kees Cook wrote:
> >> diff --git a/drivers/scsi/qedf/qedf_main.c b/drivers/scsi/qedf/qedf_main.c
> >> index cceddd995a4b..a5c97342fd5d 100644
> >> --- a/drivers/scsi/qedf/qedf_main.c
> >> +++ b/drivers/scsi/qedf/qedf_main.c
> >> @@ -2895,7 +2895,7 @@ static int __qedf_probe(struct pci_dev *pdev, int 
> >> mode)
> >>   slowpath_params.drv_minor = QEDF_DRIVER_MINOR_VER;
> >>   slowpath_params.drv_rev = QEDF_DRIVER_REV_VER;
> >>   slowpath_params.drv_eng = QEDF_DRIVER_ENG_VER;
> >> - memcpy(slowpath_params.name, "qedf", QED_DRV_VER_STR_SIZE);
> >> + strncpy(slowpath_params.name, "qedf", QED_DRV_VER_STR_SIZE);
> >>   rc = qed_ops->common->slowpath_start(qedf->cdev, _params);
> >>   if (rc) {
> >>   QEDF_ERR(&(qedf->dbg_ctx), "Cannot start slowpath.\n");
> >
> > Hello Kees,
> >
> > Although this patch looks fine to me, isn't strlcpy() preferred over 
> > strncpy()?
> 
> strlcpy doesn't zero-pad, so I think strncpy is preferred here,
> otherwise we may risk leaving portions of the destination buffer
> filled with uninitialized data, maybe leaking kernel memory contents.
> 
> -Kees
> 

I'd agree with strncpy so we zero out the rest of the buffer.

Acked-by: Chad Dupuis