From patchwork Wed Sep 26 09:41:59 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: David Hildenbrand X-Patchwork-Id: 974958 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=2001:4830:134:3::11; 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 Received: from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 42KtQ71kClz9s89 for ; Wed, 26 Sep 2018 19:47:11 +1000 (AEST) Received: from localhost ([::1]:57306 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g56PU-0004u8-Qk for incoming@patchwork.ozlabs.org; Wed, 26 Sep 2018 05:47:08 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44110) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g56LO-0001Yd-0d for qemu-devel@nongnu.org; Wed, 26 Sep 2018 05:42:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1g56LK-00033Y-SC for qemu-devel@nongnu.org; Wed, 26 Sep 2018 05:42:53 -0400 Received: from mx1.redhat.com ([209.132.183.28]:39594) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1g56LK-00033F-Kd; Wed, 26 Sep 2018 05:42:50 -0400 Received: from smtp.corp.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id DCF4830E4EB3; Wed, 26 Sep 2018 09:42:49 +0000 (UTC) Received: from t460s.redhat.com (ovpn-117-98.ams2.redhat.com [10.36.117.98]) by smtp.corp.redhat.com (Postfix) with ESMTP id 5088C2015C02; Wed, 26 Sep 2018 09:42:43 +0000 (UTC) From: David Hildenbrand To: qemu-devel@nongnu.org Date: Wed, 26 Sep 2018 11:41:59 +0200 Message-Id: <20180926094219.20322-5-david@redhat.com> In-Reply-To: <20180926094219.20322-1-david@redhat.com> References: <20180926094219.20322-1-david@redhat.com> X-Scanned-By: MIMEDefang 2.84 on 10.5.11.25 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.43]); Wed, 26 Sep 2018 09:42:50 +0000 (UTC) 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 v4 04/24] memory-device: handle integer overflows properly 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: Pankaj Gupta , Eduardo Habkost , "Michael S . Tsirkin" , Xiao Guangrong , David Hildenbrand , "Dr . David Alan Gilbert" , Markus Armbruster , Alexander Graf , qemu-ppc@nongnu.org, Paolo Bonzini , Igor Mammedov , Luiz Capitulino , David Gibson , Richard Henderson Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Sender: "Qemu-devel" Although unlikely in practice, we could have integer overflows on some calculations based on addresses and sizes, leading to error checks not triggering. Let's properly handle this whenever we do an addition. Make address_space_end point at the real end, instead of end + 1, so we don't have to handle special cases like it being 0. This will allow us to place a memory device at the very end of the guest physical 64bit address space (if ever possible). Also, QEMU_ALIGN_UP(md_addr + md_size, align) could (theoretically) wrap to address 0, so add a final check for 0. Reported-by: Dr. David Alan Gilbert Reviewed-by: David Gibson Signed-off-by: David Hildenbrand --- hw/mem/memory-device.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/hw/mem/memory-device.c b/hw/mem/memory-device.c index 7c706fadfc..8f0b9a9898 100644 --- a/hw/mem/memory-device.c +++ b/hw/mem/memory-device.c @@ -85,7 +85,8 @@ static void memory_device_check_addable(MachineState *ms, uint64_t size, /* will we exceed the total amount of memory specified */ memory_device_used_region_size(OBJECT(ms), &used_region_size); - if (used_region_size + size > ms->maxram_size - ms->ram_size) { + if (used_region_size + size < used_region_size || + used_region_size + size > ms->maxram_size - ms->ram_size) { error_setg(errp, "not enough space, currently 0x%" PRIx64 " in use of total hot pluggable 0x" RAM_ADDR_FMT, used_region_size, ms->maxram_size - ms->ram_size); @@ -115,7 +116,7 @@ uint64_t memory_device_get_free_addr(MachineState *ms, const uint64_t *hint, } address_space_start = ms->device_memory->base; address_space_end = address_space_start + - memory_region_size(&ms->device_memory->mr); + memory_region_size(&ms->device_memory->mr) - 1; g_assert(address_space_end >= address_space_start); /* address_space_start indicates the maximum alignment we expect */ @@ -149,7 +150,8 @@ uint64_t memory_device_get_free_addr(MachineState *ms, const uint64_t *hint, "] before 0x%" PRIx64, new_addr, size, address_space_start); return 0; - } else if ((new_addr + size) > address_space_end) { + } else if (new_addr + size - 1 < new_addr || + new_addr + size - 1 > address_space_end) { error_setg(errp, "can't add memory [0x%" PRIx64 ":0x%" PRIx64 "] beyond 0x%" PRIx64, new_addr, size, address_space_end); @@ -182,7 +184,8 @@ uint64_t memory_device_get_free_addr(MachineState *ms, const uint64_t *hint, } } - if (new_addr + size > address_space_end) { + if (new_addr + size - 1 < new_addr || !new_addr || + new_addr + size - 1 > address_space_end) { error_setg(errp, "could not find position in guest address space for " "memory device - memory fragmented due to alignments"); goto out;