Received: by 2002:ac0:a581:0:0:0:0:0 with SMTP id m1-v6csp66724imm; Tue, 19 Jun 2018 16:04:13 -0700 (PDT) X-Google-Smtp-Source: ADUXVKLRYdO5F952mSpeOdiAqVTQtrBpPw04b8xXTJQy3tle9KM9jckJWlVLmCJLAYardljpwA0B X-Received: by 2002:a17:902:b81:: with SMTP id 1-v6mr21254787plr.164.1529449453501; Tue, 19 Jun 2018 16:04:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1529449453; cv=none; d=google.com; s=arc-20160816; b=arUoBbvxdIA1uxm3ObBaNOEo6iUr5+wXtaubGT52nDt8G2E3d4MNyQJ5YlT4Bwu6RB DOZFrIRubhMAif/6aYfOYLpDmmGaClAId67HrEdnJcRvpUeJUrhgXaeCutXFHa9cXIrC 6Bno1MtWjzLxMFj5sJwy+tPMfxSjvgD0ecuDYRmtzcmolGiNCZPNAOPo+p1q8h0Ir5GN DMsbo/x+f7fllAA2hHYE1el1UyP15LrSpqrimWxmxMEOCFEKHn1xLPV60CP+aZkb+dpv rayouZokEmiMfZ7rQiMl39rT01DrqVA9SS44CKHJqdbqA69ISJV4+tSduz4nEU7zT+Lj S8rQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date :arc-authentication-results; bh=4g7U7h2p8vUBUjE3zqnqABp/l8ojzEPXr7NDk4UOKYQ=; b=gMxUoa1dzLTnmNax2cE9FjVbOt+4v+e4ZssJC8XEroAkpm8hWWkDcVI4SFR/tdecKc 3KG8SqL+K8SdSl5/NGFRQpEaRVGZTzBE/T9vCtDJtB3/uwbEqqGd82xhMmyjxuyeKGUr JIdITXzZVPrsBwuU7ZP/RsOK438YVfMJ/u9w1jx+pPwydFpYXvNC4scbteqUCTPMBgeW DKNfhKncB9V20dZQBRYFuvWaZGQ5QwY4c0VetvFQdKCmAvnJ0jRtsM90ro8KHz5LShec DOh3x7yOzTFuSM0b7InePm16in6oH57LRcsuucZny7BmdvLNJID1cZCunLzHJgwWT+n/ +e6w== 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 j61-v6si779670plb.68.2018.06.19.16.03.59; Tue, 19 Jun 2018 16:04:13 -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 S1754161AbeFSXB5 (ORCPT + 99 others); Tue, 19 Jun 2018 19:01:57 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:39734 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751003AbeFSXBy (ORCPT ); Tue, 19 Jun 2018 19:01:54 -0400 Received: from localhost (s169.156.222.122.fls.vectant.ne.jp [122.222.156.169]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id B4FFD100B; Tue, 19 Jun 2018 23:01:53 +0000 (UTC) Date: Wed, 20 Jun 2018 07:56:03 +0900 From: Greg Kroah-Hartman To: Alistair Strachan Cc: linux-kernel@vger.kernel.org, Arve =?iso-8859-1?B?SGr4bm5lduVn?= , Todd Kjos , Martijn Coenen , devel@driverdev.osuosl.org, kernel-team@android.com Subject: Re: [PATCH] staging: android: ashmem: Fix mmap size validation Message-ID: <20180619225603.GB23389@kroah.com> References: <20180619222444.134928-1-astrachan@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20180619222444.134928-1-astrachan@google.com> User-Agent: Mutt/1.10.0 (2018-05-17) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jun 19, 2018 at 03:24:44PM -0700, Alistair Strachan wrote: > The ashmem driver did not check that the size/offset of the vma passed > to its .mmap() function was not larger than the ashmem object being > mapped. This could cause mmap() to succeed, even though accessing parts > of the mapping would later fail with a segmentation fault. > > Ensure an error is returned by the ashmem_mmap() function if the vma > size is larger than the ashmem object size. This enables safer handling > of the problem in userspace. Is this going to break current users of this api as their original call was succeeding? > > Cc: Greg Kroah-Hartman > Cc: Arve Hj?nnev?g > Cc: Todd Kjos > Cc: Martijn Coenen > Cc: devel@driverdev.osuosl.org > Cc: kernel-team@android.com > Signed-off-by: Alistair Strachan > --- > drivers/staging/android/ashmem.c | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/drivers/staging/android/ashmem.c b/drivers/staging/android/ashmem.c > index a1a0025b59e0..1eeedb529a10 100644 > --- a/drivers/staging/android/ashmem.c > +++ b/drivers/staging/android/ashmem.c > @@ -366,6 +366,12 @@ static int ashmem_mmap(struct file *file, struct vm_area_struct *vma) > goto out; > } > > + /* requested mapping size larger than object size */ > + if (unlikely(vma->vm_end - vma->vm_start > PAGE_ALIGN(asma->size))) { > + ret = -EINVAL; > + goto out; > + } Unless you can measure the speed difference, never use likely/unlikely. The CPU and compiler almost always knows how to do this better than we do. I know there are other checks like this in this function, those should also be fixed as well. thanks, greg k-h