From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51852) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aOMZ0-0007vW-1o for qemu-devel@nongnu.org; Wed, 27 Jan 2016 04:38:58 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aOMYw-0006S4-0b for qemu-devel@nongnu.org; Wed, 27 Jan 2016 04:38:57 -0500 Received: from mx1.redhat.com ([209.132.183.28]:37229) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aOMYv-0006S0-Rs for qemu-devel@nongnu.org; Wed, 27 Jan 2016 04:38:53 -0500 Date: Wed, 27 Jan 2016 15:08:46 +0530 (IST) From: P J P In-Reply-To: <56A69E91.4080607@redhat.com> Message-ID: References: <1453732190-13416-1-git-send-email-ppandit@redhat.com> <56A63347.2030103@redhat.com> <56A69E91.4080607@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Subject: Re: [Qemu-devel] [PATCH for v2.4.1] exec: fix a glitch in checking dma r/w access List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Donghai Zdh , QEMU Developers , Peter Maydell Hello Paolo, +-- On Mon, 25 Jan 2016, Paolo Bonzini wrote --+ | This should be handled correctly by address_space_translate_internal: | | if (memory_region_is_ram(mr)) { | diff = int128_sub(section->size, int128_make64(addr)); | *plen = int128_get64(int128_min(diff, int128_make64(*plen))); | } | | ... then, on return from address_space_translate, l will be 1: | | e.g. section->size = 0x100000000, addr = 0xffffffff; | diff = 1; | *plen = min(diff, *plen) = min(1, 4) = 1 I see. Sorry, I think the issue affects versions <= v2.3.1 and not v2.4.x. v2.3.x series seems to be missing this patch -> http://git.qemu.org/?p=qemu.git;a=commit;h=23820dbfc79d1c9dce090b4c555994f2bb6a69b3 which avoids setting '*plen' to its earlier value. I'll send it to the -stable list. | You also have to test that the patch doesn't break other code. It's not | enough to test that it solves your problem. Right, I'll run the tests/* going forward. Thank you. -- Prasad J Pandit / Red Hat Product Security Team 47AF CE69 3A90 54AA 9045 1053 DD13 3D32 FE5B 041F