From patchwork Tue Feb 5 18:14:52 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Paolo Bonzini X-Patchwork-Id: 1037106 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=nongnu.org (client-ip=209.51.188.17; helo=lists.gnu.org; envelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org; receiver=) Authentication-Results: ozlabs.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="VzlUSqzx"; dkim-atps=neutral Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 43vDgY6p6pz9s7T for ; Wed, 6 Feb 2019 06:10:49 +1100 (AEDT) Received: from localhost ([127.0.0.1]:38132 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gr67L-00050F-Rr for incoming@patchwork.ozlabs.org; Tue, 05 Feb 2019 14:10:47 -0500 Received: from eggs.gnu.org ([209.51.188.92]:36430) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gr5Ge-0002cY-4P for qemu-devel@nongnu.org; Tue, 05 Feb 2019 13:16:21 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gr5Gc-00048c-Mw for qemu-devel@nongnu.org; Tue, 05 Feb 2019 13:16:20 -0500 Received: from mail-wm1-x331.google.com ([2a00:1450:4864:20::331]:53038) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gr5Gc-00044I-5d for qemu-devel@nongnu.org; Tue, 05 Feb 2019 13:16:18 -0500 Received: by mail-wm1-x331.google.com with SMTP id m1so4688284wml.2 for ; Tue, 05 Feb 2019 10:16:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:subject:date:message-id:in-reply-to:references; bh=Q4q/94jj+z0ypX5AER6s+SzJaldmbQ9+tU9nQ4E88ko=; b=VzlUSqzxT8UwjhiwhYyy480v+2j/1kYaTYG3LI9j1R7JdDKnR39BOoCXgfHsTWkCl6 Tjj3urhjGnPpiFkrr+yLwi6Tfis/fWTuUtNfzDJ0aoz+0eQz3+tFXMmcuKf1GCQHu7Oy uQL4pIx/jSN8exQtKeV2HG2XDMXbyVKZviF23GZXoInFeLxwSh+C95oCqKJ6OBVGB41T FVkdECm1SNsIcH3x5mCjgsEYXqVYRuWypfwgW5vr7PS9F0oAA8j/fQxRjSW3xtAj37BQ ktHA6eWPYJOnW2U8NqFwohD/RwrUXFEZzXjXyFzKnIb26Q+R9Nbbqpoy2BfYcoKsa75z zdoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:subject:date:message-id :in-reply-to:references; bh=Q4q/94jj+z0ypX5AER6s+SzJaldmbQ9+tU9nQ4E88ko=; b=XoBVT3VPbO0mB0O3UCArruNBU/dJsMJa9lZ889IkpXoNb8kDQhScOcwUSRhFfdC32y Kgm0GYUL/obkp910ZFdWvmsdfbBdEzc7l55DjeiXRxLzMeDIWEy8Vhgf3hdeF2N4iNty 8/4ExDdYhuPsmCZtcJRa1KiM/2EMhjAwMPmpUFh7VyMQv/v26eQ69uq7kmCFNLwJeRB5 BanIkOrDGDAvRKtkea8drDs7ZASV1STOhPjqOomNttkJCRSrneN8u0ukD6yPHCQly+eU W7IfXm48S4S44BGMOhhHUjvjjw41Y9R6ZTx6IuaKMkaPLvQJEO1c2KNPQrRfrOyd4iDk oqXA== X-Gm-Message-State: AHQUAuYXOkpyyfNvV1DeMa+5AIEtwylufY9aEBhNPsq8F6ETh7f+O9yd ZKfbI/XWMF2mufc4cILExfN26Qt/ X-Google-Smtp-Source: AHgI3IZDTR/TPO4vVjU14TIIpjRa0x0ZFHvSxS1CvLU4oQuK4L++N37Hcyf7EDQayVsJjQFHgbP8/A== X-Received: by 2002:a7b:c191:: with SMTP id y17mr22927wmi.60.1549390571928; Tue, 05 Feb 2019 10:16:11 -0800 (PST) Received: from 640k.lan ([93.56.166.5]) by smtp.gmail.com with ESMTPSA id p5sm8931665wmh.16.2019.02.05.10.16.10 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Feb 2019 10:16:11 -0800 (PST) From: Paolo Bonzini To: qemu-devel@nongnu.org Date: Tue, 5 Feb 2019 19:14:52 +0100 Message-Id: <1549390526-24246-43-git-send-email-pbonzini@redhat.com> X-Mailer: git-send-email 1.8.3.1 In-Reply-To: <1549390526-24246-1-git-send-email-pbonzini@redhat.com> References: <1549390526-24246-1-git-send-email-pbonzini@redhat.com> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::331 Subject: [Qemu-devel] [PULL 42/76] 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: , Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Sender: "Qemu-devel" Whenever the allocation length of a SCSI request is shorter than the size of 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: avoid 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 SCSI 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 --- 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 7237b41..42700e8 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 == 0x00) { + } else if (s->needs_vpd_bl_emulation && page == 0x00 && r->buflen >= 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 initialization - * 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 = lduw_be_p(r->buf + 2) + 4; - page_idx > 4 && r->buf[page_idx - 1] >= 0xb0; - page_idx--) { + page_idx = lduw_be_p(r->buf + 2) + 4; + page_idx = MIN(page_idx, r->buflen); + while (page_idx > 4 && r->buf[page_idx - 1] >= 0xb0) { if (page_idx < r->buflen) { r->buf[page_idx] = r->buf[page_idx - 1]; } + page_idx--; + } + if (page_idx < r->buflen) { + r->buf[page_idx] = 0xb0; } - r->buf[page_idx] = 0xb0; stw_be_p(r->buf + 2, lduw_be_p(r->buf + 2) + 1); } }