Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp2336035ybz; Thu, 23 Apr 2020 16:15:31 -0700 (PDT) X-Google-Smtp-Source: APiQypJBjV6Y6i8qKf7AjNrDzEN3p6nwhR1iNKfgwCcNGAMa8TeYnYAXQ70mEVaK9F9CTAHzps6t X-Received: by 2002:a17:906:7f0d:: with SMTP id d13mr4833937ejr.312.1587683730984; Thu, 23 Apr 2020 16:15:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1587683730; cv=none; d=google.com; s=arc-20160816; b=Eoi92Ht9tKKd4I9/kVUGqztslPYu43Y56eZhZOkn2oy0bPgZhV1Yqcm1Va/JxLngR0 t0v6JdjQEes8atgClJ2nU/1B/z+VUndquHTNysIf7bzpy24m8sQIdHkpN1anAwCS/O9z ZHVi4sODoVt868C9BWTUcvMEsiD+q4vDd7AwvqTU9ujoxaO7yChlWh8E1TlzybutIMKa gLvlQoADTRwKh7heSfM6eeyZsbs7D6rCH128A8/Q1SdxpfKMD45/O1GRUfVAmrp/p9PP N8rmjwpqlb7kcgnbIGUc6F+m5K7vUCLHKadSVkCdxl4TRiliZj2SEGkukAx8Na2xj3rr p3Eg== 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; bh=mAqWd2cH+8XTQG6sTyEBfKumCREvIrTH8izKG6rk5FQ=; b=eHxGpsaIPA2vPpxIyaA1EuJTg4mkmSZ8MnzX7Z31UZwxIOddCXbnlz8JupFovjoRzi AWrhYeqDR4CY0/LhUc+VDHec74yoDKvo0kaqpxnDkRQ/w8WAF1rsWNaH5mfK0STF2PE5 g921uysGTd4XoFKEwN/xpfzEKSuUnxsuoxW1Gn1W/PpoEJU+zxge/NoITSEyyKE+wf92 n5Y0MIyPtYHlvwrTcA1f2qFVKwU4pejor4ByJUdp0z7wXgdEKL8UnJUMmrRoRI8hU+mo FeQXejeTEQwTYuxMT6XNccBFSHvnu4nsme78gccmw3LR3SZ1P9IRwR9QLs7rACYOCl/B gfHQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id jr23si2032316ejb.316.2020.04.23.16.15.08; Thu, 23 Apr 2020 16:15:30 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728890AbgDWXKh (ORCPT + 99 others); Thu, 23 Apr 2020 19:10:37 -0400 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:50404 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728601AbgDWXGx (ORCPT ); Thu, 23 Apr 2020 19:06:53 -0400 Received: from [192.168.4.242] (helo=deadeye) by shadbolt.decadent.org.uk with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1jRkvf-0004tM-TR; Fri, 24 Apr 2020 00:06:48 +0100 Received: from ben by deadeye with local (Exim 4.93) (envelope-from ) id 1jRkvb-00E716-B4; Fri, 24 Apr 2020 00:06:43 +0100 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, Denis Kirjanov , "Greg Kroah-Hartman" , "Jann Horn" , "Suren Baghdasaryan" , "Joel Fernandes (Google)" , "Todd Kjos" Date: Fri, 24 Apr 2020 00:07:22 +0100 Message-ID: X-Mailer: LinuxStableQueue (scripts by bwh) X-Patchwork-Hint: ignore Subject: [PATCH 3.16 215/245] staging: android: ashmem: Disallow ashmem memory from being remapped In-Reply-To: X-SA-Exim-Connect-IP: 192.168.4.242 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.83-rc1 review patch. If anyone has any objections, please let me know. ------------------ From: Suren Baghdasaryan commit 6d67b0290b4b84c477e6a2fc6e005e174d3c7786 upstream. When ashmem file is mmapped, the resulting vma->vm_file points to the backing shmem file with the generic fops that do not check ashmem permissions like fops of ashmem do. If an mremap is done on the ashmem region, then the permission checks will be skipped. Fix that by disallowing mapping operation on the backing shmem file. Reported-by: Jann Horn Signed-off-by: Suren Baghdasaryan Signed-off-by: Todd Kjos Reviewed-by: Joel Fernandes (Google) Link: https://lore.kernel.org/r/20200127235616.48920-1-tkjos@google.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings --- drivers/staging/android/ashmem.c | 28 ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+) --- a/drivers/staging/android/ashmem.c +++ b/drivers/staging/android/ashmem.c @@ -351,8 +351,23 @@ static inline vm_flags_t calc_vm_may_fla _calc_vm_trans(prot, PROT_EXEC, VM_MAYEXEC); } +static int ashmem_vmfile_mmap(struct file *file, struct vm_area_struct *vma) +{ + /* do not allow to mmap ashmem backing shmem file directly */ + return -EPERM; +} + +static unsigned long +ashmem_vmfile_get_unmapped_area(struct file *file, unsigned long addr, + unsigned long len, unsigned long pgoff, + unsigned long flags) +{ + return current->mm->get_unmapped_area(file, addr, len, pgoff, flags); +} + static int ashmem_mmap(struct file *file, struct vm_area_struct *vma) { + static struct file_operations vmfile_fops; struct ashmem_area *asma = file->private_data; int ret = 0; @@ -386,6 +401,19 @@ static int ashmem_mmap(struct file *file goto out; } asma->file = vmfile; + /* + * override mmap operation of the vmfile so that it can't be + * remapped which would lead to creation of a new vma with no + * asma permission checks. Have to override get_unmapped_area + * as well to prevent VM_BUG_ON check for f_ops modification. + */ + if (!vmfile_fops.mmap) { + vmfile_fops = *vmfile->f_op; + vmfile_fops.mmap = ashmem_vmfile_mmap; + vmfile_fops.get_unmapped_area = + ashmem_vmfile_get_unmapped_area; + } + vmfile->f_op = &vmfile_fops; } get_file(asma->file);