From nobody Sat Apr 20 04:52:57 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.com: domain of gnu.org designates 209.51.188.17 as permitted sender) client-ip=209.51.188.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Authentication-Results: mx.zohomail.com; spf=pass (zoho.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=fail(p=none dis=none) header.from=redhat.com Return-Path: Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) by mx.zohomail.com with SMTPS id 1547225213666991.347751169335; Fri, 11 Jan 2019 08:46:53 -0800 (PST) Received: from localhost ([127.0.0.1]:43021 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ghzxF-0006xL-SB for importer@patchew.org; Fri, 11 Jan 2019 11:46:45 -0500 Received: from eggs.gnu.org ([209.51.188.92]:56642) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ghzvs-0006Ob-6E for qemu-devel@nongnu.org; Fri, 11 Jan 2019 11:45:20 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ghzvo-0001KR-Lo for qemu-devel@nongnu.org; Fri, 11 Jan 2019 11:45:17 -0500 Received: from mx1.redhat.com ([209.132.183.28]:55636) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1ghzvl-0001IM-21; Fri, 11 Jan 2019 11:45:13 -0500 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id C100F7FDE9; Fri, 11 Jan 2019 16:45:10 +0000 (UTC) Received: from donizetti.redhat.com (ovpn-112-51.ams2.redhat.com [10.36.112.51]) by smtp.corp.redhat.com (Postfix) with ESMTP id 19A736B62E; Fri, 11 Jan 2019 16:45:07 +0000 (UTC) From: Paolo Bonzini To: qemu-devel@nongnu.org Date: Fri, 11 Jan 2019 17:45:06 +0100 Message-Id: <20190111164506.15971-1-pbonzini@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Fri, 11 Jan 2019 16:45:11 +0000 (UTC) Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.132.183.28 Subject: [Qemu-devel] [PATCH] scsi-generic: avoid possible out-of-bounds access to r->buf X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Kevin Wolf , qemu-block@nongnu.org Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" Content-Type: text/plain; charset="utf-8" Whenever the allocation length of a SCSI request is shorter than the size o= f the VPD page list, page_idx is used blindly to index into r->buf. Even though the stores in the insertion sort are protected against overflows, the same = is not true of the reads and the final store of 0xb0. This basically does the same thing as commit 57dbb58d80 ("scsi-generic: avo= id out-of-bounds access to VPD page list", 2018-11-06), except that here the allocation length can be chosen by the guest. Note that according to the S= CSI standard, the contents of the PAGE LENGTH field are not altered based on the allocation length. The code was introduced by commit 6c219fc8a1 ("scsi-generic: keep VPD page list sorted", 2018-11-06) but the overflow was already possible before. Reported-by: Kevin Wolf Fixes: a71c775b24ebc664129eb1d9b4c360590353efd5 Signed-off-by: Paolo Bonzini Reviewed-by: Kevin Wolf --- hw/scsi/scsi-generic.c | 18 ++++++++++-------- 1 file changed, 10 insertions(+), 8 deletions(-) diff --git a/hw/scsi/scsi-generic.c b/hw/scsi/scsi-generic.c index 7237b4162e..42700e8897 100644 --- a/hw/scsi/scsi-generic.c +++ b/hw/scsi/scsi-generic.c @@ -182,7 +182,7 @@ static void scsi_handle_inquiry_reply(SCSIGenericReq *r= , SCSIDevice *s) /* Also take care of the opt xfer len. */ stl_be_p(&r->buf[12], MIN_NON_ZERO(max_transfer, ldl_be_p(&r->buf[12]))); - } else if (s->needs_vpd_bl_emulation && page =3D=3D 0x00) { + } else if (s->needs_vpd_bl_emulation && page =3D=3D 0x00 && r->buf= len >=3D 4) { /* * Now we're capable of supplying the VPD Block Limits * response if the hardware can't. Add it in the INQUIRY @@ -193,18 +193,20 @@ static void scsi_handle_inquiry_reply(SCSIGenericReq = *r, SCSIDevice *s) * and will use it to proper setup the SCSI device. * * VPD page numbers must be sorted, so insert 0xb0 at the - * right place with an in-place insert. After the initializat= ion - * part of the for loop is executed, the device response is - * at r[0] to r[page_idx - 1]. + * right place with an in-place insert. When the while loop + * begins the device response is at r[0] to r[page_idx - 1]. */ - for (page_idx =3D lduw_be_p(r->buf + 2) + 4; - page_idx > 4 && r->buf[page_idx - 1] >=3D 0xb0; - page_idx--) { + page_idx =3D lduw_be_p(r->buf + 2) + 4; + page_idx =3D MIN(page_idx, r->buflen); + while (page_idx > 4 && r->buf[page_idx - 1] >=3D 0xb0) { if (page_idx < r->buflen) { r->buf[page_idx] =3D r->buf[page_idx - 1]; } + page_idx--; + } + if (page_idx < r->buflen) { + r->buf[page_idx] =3D 0xb0; } - r->buf[page_idx] =3D 0xb0; stw_be_p(r->buf + 2, lduw_be_p(r->buf + 2) + 1); } } --=20 2.20.1