Received: by 10.223.185.116 with SMTP id b49csp6366363wrg; Wed, 28 Feb 2018 08:14:34 -0800 (PST) X-Google-Smtp-Source: AH8x2247DRFt51BvA9JeKqiPVzL30e/1oFRsAswNi/PL5Oq0xWb0U0XxrtUcDhyG/GfPqh0upMk8 X-Received: by 2002:a17:902:461:: with SMTP id 88-v6mr18425881ple.88.1519834474128; Wed, 28 Feb 2018 08:14:34 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519834474; cv=none; d=google.com; s=arc-20160816; b=xdKKMSQ99PrMBCPuR9M+g083R/lsLAyD1XpeurpQSkCR8QZ2J2AZ0r4ZSEQvb53wmA 5Qy1zW/66TqPiDGrOWZCESWBjY40F2SmeskSqcj2WPcUt2W71nHx+854HRIgE8EO+bWt 6AM0dsw8jjCwmykqesXnqNg4reYW3AlsvAcrhigA2luZXiXMm9jxcqsN7mfT5PbwbU2y 3Rs4lrE3vrfDecCvXmPYlMjgl0QjQjg9UVmTpDLQFddwDa3JO3N3EAOZcRFmzER5uiDb BHG6kPKENDzaEu6TMSLPYtBZ2dPI4x/S2zVnptxYOq+trNBFfHd+CZ9VnN9eWjF0Ni6k O7IA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:subject:message-id:date:cc:to :from:mime-version:content-transfer-encoding:content-disposition :arc-authentication-results; bh=gwWmIRWhU3Ui/4s+Ap2xK2niVgvaKF4QGJEkWdtgdT0=; b=oEXlZ7IdRcXUBb+Z1YjxcVEfKP2bSwfR2HLRXpE/YgOJxwjCkUvhR/kH2vjgYOmnhG Z6a4YOyKuhj/VRPFTajXUntx/Wb01G8twofer88Fghdg3gW//Ei3t/NjAp4KJoy4k9lL 2JP2uAkYHzmkQK4yONdELrM8ciFcffshrKROdih8af6ouHlIy4G96kYl1EI2GhYBPxfQ Ft85kvvTJwYwcN4CHS/SD1nOGcznpbjFOixkShqwF9ma8qACUcwCg+y6lHB2jAX0YxM6 v18jwBhGICf6kXXeGQknlEDWzehZjUMfcqVxFZX/xUCl/hGAGkEYw8kjR7mPjCgRBORV dt3A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m8-v6si1430087plt.501.2018.02.28.08.14.19; Wed, 28 Feb 2018 08:14:34 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934012AbeB1QMB (ORCPT + 99 others); Wed, 28 Feb 2018 11:12:01 -0500 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:35022 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933269AbeB1QL6 (ORCPT ); Wed, 28 Feb 2018 11:11:58 -0500 Received: from [2a02:8011:400e:2:6f00:88c8:c921:d332] (helo=deadeye) by shadbolt.decadent.org.uk with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1er3Yi-0006XP-In; Wed, 28 Feb 2018 15:22:20 +0000 Received: from ben by deadeye with local (Exim 4.90_1) (envelope-from ) id 1er3Yg-00006U-RC; Wed, 28 Feb 2018 15:22:18 +0000 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit MIME-Version: 1.0 From: Ben Hutchings To: linux-kernel@vger.kernel.org, stable@vger.kernel.org CC: akpm@linux-foundation.org, "Christoffer Dall" , "Andre Przywara" , "Marc Zyngier" Date: Wed, 28 Feb 2018 15:20:18 +0000 Message-ID: X-Mailer: LinuxStableQueue (scripts by bwh) Subject: [PATCH 3.16 119/254] KVM: arm/arm64: Fix HYP unmapping going off limits In-Reply-To: X-SA-Exim-Connect-IP: 2a02:8011:400e:2:6f00:88c8:c921:d332 X-SA-Exim-Mail-From: ben@decadent.org.uk X-SA-Exim-Scanned: No (on shadbolt.decadent.org.uk); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 3.16.55-rc1 review patch. If anyone has any objections, please let me know. ------------------ From: Marc Zyngier commit 7839c672e58bf62da8f2f0197fefb442c02ba1dd upstream. When we unmap the HYP memory, we try to be clever and unmap one PGD at a time. If we start with a non-PGD aligned address and try to unmap a whole PGD, things go horribly wrong in unmap_hyp_range (addr and end can never match, and it all goes really badly as we keep incrementing pgd and parse random memory as page tables...). The obvious fix is to let unmap_hyp_range do what it does best, which is to iterate over a range. The size of the linear mapping, which begins at PAGE_OFFSET, can be easily calculated by subtracting PAGE_OFFSET form high_memory, because high_memory is defined as the linear map address of the last byte of DRAM, plus one. The size of the vmalloc region is given trivially by VMALLOC_END - VMALLOC_START. Reported-by: Andre Przywara Tested-by: Andre Przywara Reviewed-by: Christoffer Dall Signed-off-by: Marc Zyngier Signed-off-by: Christoffer Dall [bwh: Backported to 3.16: adjust filename, context] Signed-off-by: Ben Hutchings --- arch/arm/kvm/mmu.c | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) --- a/arch/arm/kvm/mmu.c +++ b/arch/arm/kvm/mmu.c @@ -345,17 +345,15 @@ void free_boot_hyp_pgd(void) */ void free_hyp_pgds(void) { - unsigned long addr; - free_boot_hyp_pgd(); mutex_lock(&kvm_hyp_pgd_mutex); if (hyp_pgd) { - for (addr = PAGE_OFFSET; virt_addr_valid(addr); addr += PGDIR_SIZE) - unmap_range(NULL, hyp_pgd, KERN_TO_HYP(addr), PGDIR_SIZE); - for (addr = VMALLOC_START; is_vmalloc_addr((void*)addr); addr += PGDIR_SIZE) - unmap_range(NULL, hyp_pgd, KERN_TO_HYP(addr), PGDIR_SIZE); + unmap_range(NULL, hyp_pgd, KERN_TO_HYP(PAGE_OFFSET), + (uintptr_t)high_memory - PAGE_OFFSET); + unmap_range(NULL, hyp_pgd, KERN_TO_HYP(VMALLOC_START), + VMALLOC_END - VMALLOC_START); free_pages((unsigned long)hyp_pgd, pgd_order); hyp_pgd = NULL;