From nobody Wed Dec 31 17:00:56 2025 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.com: domain of gnu.org designates 208.118.235.17 as permitted sender) client-ip=208.118.235.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Authentication-Results: mx.zoho.com; spf=pass (zoho.com: domain of gnu.org designates 208.118.235.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; Return-Path: Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) by mx.zohomail.com with SMTPS id 1486536275232247.02313555169644; Tue, 7 Feb 2017 22:44:35 -0800 (PST) Received: from localhost ([::1]:57967 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cbLzW-0006eq-0u for importer@patchew.org; Wed, 08 Feb 2017 01:44:34 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60823) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cbLxU-0005Yj-5b for qemu-devel@nongnu.org; Wed, 08 Feb 2017 01:42:29 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cbLxR-0005e2-Of for qemu-devel@nongnu.org; Wed, 08 Feb 2017 01:42:28 -0500 Received: from mx1.redhat.com ([209.132.183.28]:50822) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cbLxR-0005dh-J3 for qemu-devel@nongnu.org; Wed, 08 Feb 2017 01:42:25 -0500 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id A9352C05AA43; Wed, 8 Feb 2017 06:42:25 +0000 (UTC) Received: from localhost.localdomain (ovpn-116-33.sin2.redhat.com [10.67.116.33]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id v186gGuQ032148 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 8 Feb 2017 01:42:22 -0500 From: P J P To: Qemu Developers Date: Wed, 8 Feb 2017 12:12:10 +0530 Message-Id: <20170208064212.25307-2-ppandit@redhat.com> In-Reply-To: <20170208064212.25307-1-ppandit@redhat.com> References: <20170208064212.25307-1-ppandit@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Wed, 08 Feb 2017 06:42:25 +0000 (UTC) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 209.132.183.28 Subject: [Qemu-devel] [PATCH v2 1/3] sd: sdhci: check transfer mode register in multi block transfer 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: Peter Maydell , Prasad J Pandit , "Edgar E . Iglesias" , Alistair Francis , Wjjzhang , Jiang Xin Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" X-ZohoMail: RSF_0 Z_629925259 SPT_0 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" From: Prasad J Pandit In SDHCI device emulation the transfer mode register value is used during multi block transfer to check if block count register is enabled and should be updated. Transfer mode register could be set such that, block count register would not be updated, thus leading to an infinite loop. Add check to avoid it. Reported-by: Wjjzhang Reported-by: Jiang Xin Signed-off-by: Prasad J Pandit --- hw/sd/sdhci.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) Update per: print an error message before return -> https://lists.gnu.org/archive/html/qemu-devel/2017-02/msg01567.html diff --git a/hw/sd/sdhci.c b/hw/sd/sdhci.c index 5bd5ab6..cf400c8 100644 --- a/hw/sd/sdhci.c +++ b/hw/sd/sdhci.c @@ -486,6 +486,11 @@ static void sdhci_sdma_transfer_multi_blocks(SDHCIStat= e *s) uint32_t boundary_chk =3D 1 << (((s->blksize & 0xf000) >> 12) + 12); uint32_t boundary_count =3D boundary_chk - (s->sdmasysad % boundary_ch= k); =20 + if (!(s->trnmod & SDHC_TRNS_BLK_CNT_EN) || !s->blkcnt) { + ERRPRINT("Infinite transfers are not supported\n"); + return; + } + /* XXX: Some sd/mmc drivers (for example, u-boot-slp) do not account f= or * possible stop at page boundary if initial address is not page align= ed, * allow them to work properly */ @@ -797,11 +802,6 @@ static void sdhci_data_transfer(void *opaque) if (s->trnmod & SDHC_TRNS_DMA) { switch (SDHC_DMA_TYPE(s->hostctl)) { case SDHC_CTRL_SDMA: - if ((s->trnmod & SDHC_TRNS_MULTI) && - (!(s->trnmod & SDHC_TRNS_BLK_CNT_EN) || s->blkcnt =3D= =3D 0)) { - break; - } - if ((s->blkcnt =3D=3D 1) || !(s->trnmod & SDHC_TRNS_MULTI)) { sdhci_sdma_transfer_single_block(s); } else { @@ -1050,7 +1050,7 @@ sdhci_write(void *opaque, hwaddr offset, uint64_t val= , unsigned size) if (!(s->capareg & SDHC_CAN_DO_DMA)) { value &=3D ~SDHC_TRNS_DMA; } - MASKED_WRITE(s->trnmod, mask, value); + MASKED_WRITE(s->trnmod, mask, value & 0x0037); MASKED_WRITE(s->cmdreg, mask >> 16, value >> 16); =20 /* Writing to the upper byte of CMDREG triggers SD command generat= ion */ --=20 2.9.3