Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp9463273ybi; Wed, 24 Jul 2019 04:35:30 -0700 (PDT) X-Google-Smtp-Source: APXvYqxjZyLdYK8AlpCwj4X5/xC81kssS3tIE1FCin64900FbFqKq4b8XCmfZPhb3Q9g4CmHz30T X-Received: by 2002:a63:8dc9:: with SMTP id z192mr26750939pgd.151.1563968130403; Wed, 24 Jul 2019 04:35:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1563968130; cv=none; d=google.com; s=arc-20160816; b=aUmTx4Iln2XYBzigj4NgKuCM3mE+pIpx+lLIyV0S9XCtFnmQS7PePBcrbZ4iHFB1ne 6wKHYsKMJr7yCG+42ubjIgc1s/dXKqVx/9oCydzNu+Rzv0w0GoTa4BKjnniqUXjzrRr4 MJ4ILxfRRJVIvWGX1rm3u1qN8DaBggq3YxG6uY5LjAbqyxDMiaHB6WtohLHcZFGnDFZl aunWJ7jep+geSI4bI1hWVY34pfp82mjalaOlgVvAtbX4gllBU8t/7FHfSt09Dw2Hxm05 wFM7FSqwQNWUKFjWwRTIN8wX2RVsBMp8wnKJk3N2FV8IKlijzAlv4ccKO6UiqySuvcxC Xsvw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date; bh=kHm14qGQU8/qjdN3lFZHsidt0srT4OujFTBgY9P5x6c=; b=H5ujgqCOsffBsXonJrvcQA48yHVeW5c3NKt+qkoyHA7iNWdHGxpvX0CLaYjbtNz/bd 8nJqNyyQY6k72BMBj/kiOQDJo2o8745EZdQaHBwgU/XX3taX3/tHsmavrZ/zYbJpJ6gU YJJdFeZcVlE3Chyyf/+TKi0ire2e7fidaFf65yvlOJVSx/xt6os5EEA9vAdI32qKbyyc g8F2LZ0rHwjosf0tPqz60pH0E9URHjXSJxIkbbTsIJn6aMMGaLayV1GHCK+TlMvZZSEi fKPPEUhpdeprRt69YkL1NwS1XbEapGnVj82Aexyfkz91e7fiX0y4x8JOTG73SRA6tr6e fxLQ== 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 g18si5197292plq.190.2019.07.24.04.35.15; Wed, 24 Jul 2019 04:35:30 -0700 (PDT) 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 S1727465AbfGXLef (ORCPT + 99 others); Wed, 24 Jul 2019 07:34:35 -0400 Received: from Galois.linutronix.de ([193.142.43.55]:43804 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727083AbfGXLef (ORCPT ); Wed, 24 Jul 2019 07:34:35 -0400 Received: from pd9ef1cb8.dip0.t-ipconnect.de ([217.239.28.184] helo=nanos) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1hqFXL-0006JX-US; Wed, 24 Jul 2019 13:34:24 +0200 Date: Wed, 24 Jul 2019 13:34:23 +0200 (CEST) From: Thomas Gleixner To: Jia-Ju Bai cc: dave.hansen@linux.intel.com, luto@kernel.org, peterz@infradead.org, mingo@redhat.com, bp@alien8.de, hpa@zytor.com, x86@kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] x86: Fix possible null-pointer dereferences in untrack_pfn() In-Reply-To: Message-ID: References: <20190723132648.25853-1-baijiaju1990@gmail.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 24 Jul 2019, Thomas Gleixner wrote: > On Tue, 23 Jul 2019, Jia-Ju Bai wrote: > > > In untrack_pfn(), there is an if statement on line 1058 to check whether > > vma is NULL: > > if (vma && !(vma->vm_flags & VM_PAT)) > > > > When vma is NULL, vma is used on line 1064: > > if (follow_phys(vma, vma->vm_start, 0, &prot, &paddr)) > > and line 1069: > > size = vma->vm_end - vma->vm_start; > > > > Thus, possible null-pointer dereferences may occur. > > > > To fix these possible bugs, vma is checked on line 1063. > > > > These bugs are found by a static analysis tool STCheck written by us. > > In principle you are right, but that's a bit more subtle as the callers can > provide a vma pointer and/or a valid pfn and size. > > > diff --git a/arch/x86/mm/pat.c b/arch/x86/mm/pat.c > > index d9fbd4f69920..717456e7745e 100644 > > --- a/arch/x86/mm/pat.c > > +++ b/arch/x86/mm/pat.c > > @@ -1060,7 +1060,7 @@ void untrack_pfn(struct vm_area_struct *vma, unsigned long pfn, > > > > /* free the chunk starting from pfn or the whole chunk */ > > paddr = (resource_size_t)pfn << PAGE_SHIFT; > > - if (!paddr && !size) { > > + if (vma && !paddr && !size) { > > if (follow_phys(vma, vma->vm_start, 0, &prot, &paddr)) { > > WARN_ON_ONCE(1); > > return; > > So I'd rather have a sanity check in that function which does: > > if (WARN_ON_ONCE(!vma && !pfn && !size)) > return; The even better solution is to have separate functions: untrack_pfn(unsigned long pfn, unsigned long size) and untrack_vma(struct vm_area_struct *vma, unsigned long pfn, unsigned long size) The amount of shared code is minimal and the result is less confusing. Thanks, tglx