linux-kernel - Re: [PATCH 1/1] scsi: Fix possible buffer overflows in storvsc

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>] [day] [month] [year] [list]

Message-ID: <20201209133146.yskq5rnxpdaiqhrc@liuwe-devbox-debian-v2>
Date:   Wed, 9 Dec 2020 13:31:46 +0000
From:   Wei Liu <wei.liu@...nel.org>
To:     Xiaohui Zhang <ruc_zhangxiaohui@....com>
Cc:     Michael Kelley <mikelley@...rosoft.com>,
        KY Srinivasan <kys@...rosoft.com>,
        Haiyang Zhang <haiyangz@...rosoft.com>,
        Stephen Hemminger <sthemmin@...rosoft.com>,
        Wei Liu <wei.liu@...nel.org>,
        "James E.J. Bottomley" <jejb@...ux.ibm.com>,
        "Martin K. Petersen" <martin.petersen@...cle.com>,
        "linux-hyperv@...r.kernel.org" <linux-hyperv@...r.kernel.org>,
        "linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/1] scsi: Fix possible buffer overflows in
 storvsc_queuecommand

On Wed, Dec 09, 2020 at 09:25:23AM +0800, Xiaohui Zhang wrote:
> 
> 
> 
> At 2020-12-09 01:52:42, "Michael Kelley" <mikelley@...rosoft.com> wrote:
> >From: Xiaohui Zhang <ruc_zhangxiaohui@....com>  Sent: Tuesday, December 8, 2020 5:19 AM
> >> 
> >> From: Zhang Xiaohui <ruc_zhangxiaohui@....com>
> >> 
> >> storvsc_queuecommand() calls memcpy() without checking
> >> the destination size may trigger a buffer overflower,
> >> which a local user could use to cause denial of service
> >> or the execution of arbitrary code.
> >> Fix it by putting the length check before calling memcpy().
> >> 
> >> Signed-off-by: Zhang Xiaohui <ruc_zhangxiaohui@....com>
> >> ---
> >>  drivers/scsi/storvsc_drv.c | 2 ++
> >>  1 file changed, 2 insertions(+)
> >> 
> >> diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
> >> index 0c65fbd41..09b60a4c0 100644
> >> --- a/drivers/scsi/storvsc_drv.c
> >> +++ b/drivers/scsi/storvsc_drv.c
> >> @@ -1729,6 +1729,8 @@ static int storvsc_queuecommand(struct Scsi_Host *host, struct
> >> scsi_cmnd *scmnd)
> >> 
> >>  	vm_srb->cdb_length = scmnd->cmd_len;
> >> 
> >> +	if (vm_srb->cdb_length > STORVSC_MAX_CMD_LEN)
> >> +		vm_srb->cdb_length = STORVSC_MAX_CMD_LEN;
> >>  	memcpy(vm_srb->cdb, scmnd->cmnd, vm_srb->cdb_length);
> >> 
> >>  	sgl = (struct scatterlist *)scsi_sglist(scmnd);
> >> --
> >> 2.17.1
> >
> >At first glance, this new test isn't necessary.  storvsc_queuecommand() gets
> >called from scsi_dispatch_cmd(), where just before the queuecommand function
> >is called, the cmd_len field is checked against the maximum command length
> >defined for the SCSI controller.  In the case of storvsc, that maximum command
> >length is STORVSC_MAX_CMD_LEN as set in storvsc_probe().  There's a comment
> >in scsi_dispatch_cmd() that covers this exact case.
> >
> >You are correct that we need to make sure there's no buffer overflow.  Are
> >you seeing any other path where storvsc_queuecommand() could be called
> 
> >without the cmd_len being checked?
> 
> 
> Hello, maybe storvsc_queuecommand() could be called without the cmd_len 
> being checked in scsi_send_eh_cmnd().

In that case, a better approach is to fix the SCSI layer instead of
individual drivers, right? Storvsc can't be the only one that is
affected by this issue.

Truncating the command solves the buffer overflow issue but it doesn't
make sense to issue a truncated command to the controller.

Wei.