lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <D656EC82.4ACF8%manish.rangankar@cavium.com>
Date:   Wed, 13 Dec 2017 09:12:11 +0000
From:   "Rangankar, Manish" <Manish.Rangankar@...ium.com>
To:     Jia-Ju Bai <baijiaju1990@...il.com>,
        Dept-Eng QLogic Storage Upstream 
        <QLogic-Storage-Upstream@...ium.com>,
        "jejb@...ux.vnet.ibm.com" <jejb@...ux.vnet.ibm.com>,
        "martin.petersen@...cle.com" <martin.petersen@...cle.com>
CC:     "linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] qedi: Fix a possible sleep-in-atomic bug in
 qedi_process_tmf_resp



On 13/12/17 2:41 PM, "Jia-Ju Bai" <baijiaju1990@...il.com> wrote:

>The driver may sleep under a spinlock.
>The function call path is:
>qedi_cpu_offline (acquire the spinlock)
>  qedi_fp_process_cqes
>    qedi_mtask_completion
>      qedi_process_tmf_resp
>        kzalloc(GFP_KERNEL) --> may sleep
>
>To fix it, GFP_KERNEL is replaced with GFP_ATOMIC.
>
>This bug is found by my static analysis tool(DSAC) and checked by my code
>review.
>
>Signed-off-by: Jia-Ju Bai <baijiaju1990@...il.com>
>---
> drivers/scsi/qedi/qedi_fw.c |    2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/drivers/scsi/qedi/qedi_fw.c b/drivers/scsi/qedi/qedi_fw.c
>index bd302d3..20a9259 100644
>--- a/drivers/scsi/qedi/qedi_fw.c
>+++ b/drivers/scsi/qedi/qedi_fw.c
>@@ -198,7 +198,7 @@ static void qedi_process_tmf_resp(struct qedi_ctx
>*qedi,
> 	cqe_tmp_response = &cqe->cqe_common.iscsi_hdr.tmf_response;
> 
> 	qedi_cmd = task->dd_data;
>-	qedi_cmd->tmf_resp_buf = kzalloc(sizeof(*resp_hdr_ptr), GFP_KERNEL);
>+	qedi_cmd->tmf_resp_buf = kzalloc(sizeof(*resp_hdr_ptr), GFP_ATOMIC);
> 	if (!qedi_cmd->tmf_resp_buf) {
> 		QEDI_ERR(&qedi->dbg_ctx,
> 			 "Failed to allocate resp buf, cid=0x%x\n",
>-- 
>1.7.9.5

Thanks,

Acked-by: Manish Rangankar <Manish.Rangankar@...ium.com>

>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ