From patchwork Wed Feb 24 20:04:33 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Morton X-Patchwork-Id: 12102567 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=-15.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 BADE2C43381 for ; Wed, 24 Feb 2021 20:04:36 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 5C2F064F33 for ; Wed, 24 Feb 2021 20:04:36 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5C2F064F33 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id E0AD38D0009; Wed, 24 Feb 2021 15:04:35 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id DBA496B00A3; Wed, 24 Feb 2021 15:04:35 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CF68F8D0009; Wed, 24 Feb 2021 15:04:35 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0122.hostedemail.com [216.40.44.122]) by kanga.kvack.org (Postfix) with ESMTP id B9FD16B00A2 for ; Wed, 24 Feb 2021 15:04:35 -0500 (EST) Received: from smtpin16.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 859DCFB55 for ; Wed, 24 Feb 2021 20:04:35 +0000 (UTC) X-FDA: 77854238910.16.1BF29CF Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf18.hostedemail.com (Postfix) with ESMTP id 5D2E8200038A for ; Wed, 24 Feb 2021 20:04:36 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id ABA4A64F28; Wed, 24 Feb 2021 20:04:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1614197074; bh=ZMX7Cyocnd5Q+RWAIfyBqoozo9BNvXR0pWfWkaU5ECc=; h=Date:From:To:Subject:In-Reply-To:From; b=Q4uIjkespeCCnpFojjEr203EFyBUxFVSV+NOJRgkPQ8emcv2Tb5pYEbW33IJqI+xS NMvfm47pNoK8EeN7rOQer0wzdD0c9aLJv5efeke97RiluBIAo9txWtma2/ceIXinQQ aV8NiAUvPhBRaCKpmfBbSvuerJ44GkGXV3zkN/pQ= Date: Wed, 24 Feb 2021 12:04:33 -0800 From: Andrew Morton To: ak@linux.intel.com, akpm@linux-foundation.org, dave.hansen@intel.com, jpoimboe@redhat.com, linmiaohe@huawei.com, linux-mm@kvack.org, louhongxiang@huawei.com, mm-commits@vger.kernel.org, tglx@linutronix.de, torvalds@linux-foundation.org Subject: [patch 077/173] mm/memory.c: fix potential pte_unmap_unlock pte error Message-ID: <20210224200433.NUH3KlBjC%akpm@linux-foundation.org> In-Reply-To: <20210224115824.1e289a6895087f10c41dd8d6@linux-foundation.org> User-Agent: s-nail v14.8.16 X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 5D2E8200038A X-Stat-Signature: pc6xi8ogmy8ozk97khxq454fjo8j4mx1 Received-SPF: none (linux-foundation.org>: No applicable sender policy available) receiver=imf18; identity=mailfrom; envelope-from=""; helo=mail.kernel.org; client-ip=198.145.29.99 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1614197076-394790 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: From: Miaohe Lin Subject: mm/memory.c: fix potential pte_unmap_unlock pte error Since commit 42e4089c7890 ("x86/speculation/l1tf: Disallow non privileged high MMIO PROT_NONE mappings"), when the first pfn modify is not allowed, we would break the loop with pte unchanged. Then the wrong pte - 1 would be passed to pte_unmap_unlock. Andi said: : While the fix is correct, I'm not sure if it actually is a real bug. Is : there any architecture that would do something else than unlocking the : underlying page? If it's just the underlying page then it should be : always the same page, so no bug. Link: https://lkml.kernel.org/r/20210109080118.20885-1-linmiaohe@huawei.com Fixes: 42e4089c789 ("x86/speculation/l1tf: Disallow non privileged high MMIO PROT_NONE mappings") Signed-off-by: Hongxiang Lou Signed-off-by: Miaohe Lin Cc: Thomas Gleixner Cc: Dave Hansen Cc: Andi Kleen Cc: Josh Poimboeuf Signed-off-by: Andrew Morton --- mm/memory.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) --- a/mm/memory.c~mm-fix-potential-pte_unmap_unlock-pte-error +++ a/mm/memory.c @@ -2177,11 +2177,11 @@ static int remap_pte_range(struct mm_str unsigned long addr, unsigned long end, unsigned long pfn, pgprot_t prot) { - pte_t *pte; + pte_t *pte, *mapped_pte; spinlock_t *ptl; int err = 0; - pte = pte_alloc_map_lock(mm, pmd, addr, &ptl); + mapped_pte = pte = pte_alloc_map_lock(mm, pmd, addr, &ptl); if (!pte) return -ENOMEM; arch_enter_lazy_mmu_mode(); @@ -2195,7 +2195,7 @@ static int remap_pte_range(struct mm_str pfn++; } while (pte++, addr += PAGE_SIZE, addr != end); arch_leave_lazy_mmu_mode(); - pte_unmap_unlock(pte - 1, ptl); + pte_unmap_unlock(mapped_pte, ptl); return err; }