Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932331AbcKGNVx (ORCPT ); Mon, 7 Nov 2016 08:21:53 -0500 Received: from mx2.suse.de ([195.135.220.15]:36892 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932267AbcKGNFc (ORCPT ); Mon, 7 Nov 2016 08:05:32 -0500 X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "References" From: Jiri Slaby To: stable@vger.kernel.org Cc: linux-kernel@vger.kernel.org, Paul Mackerras , Michael Ellerman , Jiri Slaby Subject: [PATCH 3.12 18/72] powerpc/64: Fix incorrect return value from __copy_tofrom_user Date: Mon, 7 Nov 2016 14:04:25 +0100 Message-Id: <61bc5e39f2a0720c58f0db6679912c6cb6d2fb52.1478523828.git.jslaby@suse.cz> X-Mailer: git-send-email 2.10.2 In-Reply-To: <0f3caac741164dcff670ae0f4d1cfcb0a7026a1c.1478523828.git.jslaby@suse.cz> References: <0f3caac741164dcff670ae0f4d1cfcb0a7026a1c.1478523828.git.jslaby@suse.cz> In-Reply-To: References: Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2122 Lines: 60 From: Paul Mackerras 3.12-stable review patch. If anyone has any objections, please let me know. =============== commit 1a34439e5a0b2235e43f96816dbb15ee1154f656 upstream. Debugging a data corruption issue with virtio-net/vhost-net led to the observation that __copy_tofrom_user was occasionally returning a value 16 larger than it should. Since the return value from __copy_tofrom_user is the number of bytes not copied, this means that __copy_tofrom_user can occasionally return a value larger than the number of bytes it was asked to copy. In turn this can cause higher-level copy functions such as copy_page_to_iter_iovec to corrupt memory by copying data into the wrong memory locations. It turns out that the failing case involves a fault on the store at label 79, and at that point the first unmodified byte of the destination is at R3 + 16. Consequently the exception handler for that store needs to add 16 to R3 before using it to work out how many bytes were not copied, but in this one case it was not adding the offset to R3. To fix it, this moves the label 179 to the point where we add 16 to R3. I have checked manually all the exception handlers for the loads and stores in this code and the rest of them are correct (it would be excellent to have an automated test of all the exception cases). This bug has been present since this code was initially committed in May 2002 to Linux version 2.5.20. Signed-off-by: Paul Mackerras Signed-off-by: Michael Ellerman Signed-off-by: Jiri Slaby --- arch/powerpc/lib/copyuser_64.S | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/powerpc/lib/copyuser_64.S b/arch/powerpc/lib/copyuser_64.S index d73a59014900..be94e1be4ae3 100644 --- a/arch/powerpc/lib/copyuser_64.S +++ b/arch/powerpc/lib/copyuser_64.S @@ -336,6 +336,7 @@ END_FTR_SECTION_IFCLR(CPU_FTR_UNALIGNED_LD_STD) addi r3,r3,8 171: 177: +179: addi r3,r3,8 370: 372: @@ -350,7 +351,6 @@ END_FTR_SECTION_IFCLR(CPU_FTR_UNALIGNED_LD_STD) 173: 174: 175: -179: 181: 184: 186: -- 2.10.2