From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-9.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 50214C43381 for ; Tue, 26 Mar 2019 00:18:50 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 1AF5920848 for ; Tue, 26 Mar 2019 00:18:50 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=nvidia.com header.i=@nvidia.com header.b="irgfQneN" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730180AbfCZASs (ORCPT ); Mon, 25 Mar 2019 20:18:48 -0400 Received: from hqemgate15.nvidia.com ([216.228.121.64]:15639 "EHLO hqemgate15.nvidia.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726186AbfCZASr (ORCPT ); Mon, 25 Mar 2019 20:18:47 -0400 Received: from hqpgpgate102.nvidia.com (Not Verified[216.228.121.13]) by hqemgate15.nvidia.com (using TLS: TLSv1.2, DES-CBC3-SHA) id ; Mon, 25 Mar 2019 17:18:42 -0700 Received: from hqmail.nvidia.com ([172.20.161.6]) by hqpgpgate102.nvidia.com (PGP Universal service); Mon, 25 Mar 2019 17:18:46 -0700 X-PGP-Universal: processed; by hqpgpgate102.nvidia.com on Mon, 25 Mar 2019 17:18:46 -0700 Received: from rcampbell-dev.nvidia.com (10.124.1.5) by HQMAIL101.nvidia.com (172.20.187.10) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 26 Mar 2019 00:18:46 +0000 From: To: CC: Ralph Campbell , Craig Bergstrom , Linus Torvalds , Boris Ostrovsky , Fengguang Wu , Greg Kroah-Hartman , Hans Verkuil , Mauro Carvalho Chehab , Peter Zijlstra , Sander Eikelenboom , Sean Young , Thomas Gleixner , Ingo Molnar Subject: [PATCH v2 1/1] x86/mm: Fix limit mmap() of /dev/mem to valid physical addresses Date: Mon, 25 Mar 2019 17:18:17 -0700 Message-ID: <20190326001817.15413-2-rcampbell@nvidia.com> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20190326001817.15413-1-rcampbell@nvidia.com> References: <20190326001817.15413-1-rcampbell@nvidia.com> MIME-Version: 1.0 X-NVConfidentiality: public X-Originating-IP: [10.124.1.5] X-ClientProxiedBy: HQMAIL105.nvidia.com (172.20.187.12) To HQMAIL101.nvidia.com (172.20.187.10) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nvidia.com; s=n1; t=1553559522; bh=rug7tppjj0W6yolK2JQNky95da2OiKZcEc1JvEU0dnM=; h=X-PGP-Universal:From:To:CC:Subject:Date:Message-ID:X-Mailer: In-Reply-To:References:MIME-Version:X-NVConfidentiality: X-Originating-IP:X-ClientProxiedBy:Content-Transfer-Encoding: Content-Type; b=irgfQneNrpXsg0Bnp+ByqmerIiNBQGqo/rGF6JoFT04m5vKgBZ8q11nhkKPOJ8y1n 00mXg5wX8vY51MKtyhFB1dQXb9O2eq2yF1M1XswkFm5KyiT/vWvUIXRhZaSHwzByR8 moNLS+vVi/w/Fcsanx6KG5hMt/J1ODqBAikq88eZD65kIHIq7IwT7vJAx7YJudMLKS dNayuoT8VrD9/rjfK31F03P2iD691PWbnfQTKmPcM1Rn++k26MtAoickPSPsC9t0V/ anpFgVgIIh6hIOS/X6w/aNzOGojd3pliLW3qt5X/HNXmu3igoHYDuQ3XHxu07xLEJn ai9GJ35WS/aag== Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Ralph Campbell valid_phys_addr_range() is used to sanity check the physical address range of an operation, e.g., access to /dev/mem. It uses __pa(high_memory) internally. If memory is populated at the end of the physical address space, then __pa(high_memory) is outside of the physical address space because: high_memory =3D (void *)__va(max_pfn * PAGE_SIZE - 1) + 1; For the comparison in valid_phys_addr_range() this is not an issue, but if CONFIG_DEBUG_VIRTUAL is enabled, __pa() maps to __phys_addr(), which verifies that the resulting physical address is within the valid physical address space of the CPU. So in the case that memory is populated at the end of the physical address space, this is not true and triggers a VIRTUAL_BUG_ON(). Use __pa(high_memory - 1) to prevent the conversion from going beyond the end of valid physical addresses. Fixes: be62a3204406 ("x86/mm: Limit mmap() of /dev/mem to valid physical ad= dresses") Signed-off-by: Ralph Campbell Cc: Craig Bergstrom Cc: Linus Torvalds Cc: Boris Ostrovsky Cc: Fengguang Wu Cc: Greg Kroah-Hartman Cc: Hans Verkuil Cc: Mauro Carvalho Chehab Cc: Peter Zijlstra Cc: Sander Eikelenboom Cc: Sean Young Cc: Thomas Gleixner Cc: Ingo Molnar --- arch/x86/mm/mmap.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/mm/mmap.c b/arch/x86/mm/mmap.c index db3165714521..196bed43d5e6 100644 --- a/arch/x86/mm/mmap.c +++ b/arch/x86/mm/mmap.c @@ -230,7 +230,7 @@ bool mmap_address_hint_valid(unsigned long addr, unsign= ed long len) /* Can we access it for direct reading/writing? Must be RAM: */ int valid_phys_addr_range(phys_addr_t addr, size_t count) { - return addr + count <=3D __pa(high_memory); + return addr + count - 1 <=3D __pa(high_memory - 1); } =20 /* Can we access it through mmap? Must be a valid physical address: */ --=20 2.20.1