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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id CBBA2C369BA for ; Wed, 25 Sep 2024 09:49:05 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2F5B86B0083; Wed, 25 Sep 2024 05:49:05 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2A63D6B0085; Wed, 25 Sep 2024 05:49:05 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1468B6B0088; Wed, 25 Sep 2024 05:49:05 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id E45766B0083 for ; Wed, 25 Sep 2024 05:49:04 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 94832AC2B0 for ; Wed, 25 Sep 2024 09:49:04 +0000 (UTC) X-FDA: 82602787008.08.68BB6C1 Received: from mail-lf1-f49.google.com (mail-lf1-f49.google.com [209.85.167.49]) by imf29.hostedemail.com (Postfix) with ESMTP id B61BF120014 for ; Wed, 25 Sep 2024 09:49:02 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=QqFrCXdx; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf29.hostedemail.com: domain of ebpqwerty472123@gmail.com designates 209.85.167.49 as permitted sender) smtp.mailfrom=ebpqwerty472123@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1727257707; a=rsa-sha256; cv=none; b=0kvnlYypJHiHz9vO8XcMOrdHwcDRb/X8eOxBK6YDN7bWh5Qtv6TR3M2SvZHBRegyN34BkI 8pONd/nJ8KfQGbnUbo+8HsAmkdExOlkOzfQtkORwGTtYDBgOoU/hXeGmEcErIoV7pyDKzm yUFC8gmaoC27jXfECkKK+auww2fC1t8= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=QqFrCXdx; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf29.hostedemail.com: domain of ebpqwerty472123@gmail.com designates 209.85.167.49 as permitted sender) smtp.mailfrom=ebpqwerty472123@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1727257707; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=K8XLjvV0Uhz8/lsidK2GZAkhOD7DZjaxTggs1N63dxw=; b=k4MgMdabasia8UsCSA10x3ZYDAni7rru3/loKQrX7SqKaSfkGCQnRajLYqo+RbnRFckVJQ cxL0HFwJoxKQ7TyYrEg/OGkv7lE8w7HgKKYKBO60ljCwGqer4ZRy6w87S+pRpr7xsWLwY8 DBPglKo620a0XRwORzj8CWhoaRHSlJ8= Received: by mail-lf1-f49.google.com with SMTP id 2adb3069b0e04-535be093a43so8122923e87.3 for ; Wed, 25 Sep 2024 02:49:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1727257741; x=1727862541; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=K8XLjvV0Uhz8/lsidK2GZAkhOD7DZjaxTggs1N63dxw=; b=QqFrCXdx9r+f5SXQIwn2ipnbOEqXQW955XlcHd/+Wkj2uwkpPHm2zAuTPB1EvV7ZAJ oMPvt3+B3jMWS+3lmp/61LenCqpJmrSonU/jh28sBiNB8NfdBPzTelrxWil8LzWXz3pb eCOD8yHhVujBxSfYCqhIpFkWD6akQe7cSXhmSP5+4uSKdgxKrAmgwRmc5wJJowOXbFKd 5O5wfoX0U1RDGrL5KS4dMaDOaNmcTrEeUP4/kBNLIsPO4qE+PgbP8GXoFJRn9L7mScQB v7tAE4UKlwbL1kL/y3BD1FMeu+LDAkq7So54M0ZgokbEdcQcpJJsO+wjt68iDngaWUpR XUSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727257741; x=1727862541; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=K8XLjvV0Uhz8/lsidK2GZAkhOD7DZjaxTggs1N63dxw=; b=u2WVXg3Tx4E/S4OHxe7WXQm/9AyxtT6SxHrm6QiDilEZlk7AfipV3fcy20DKZguEj3 eV3Bcg1q1A4wSWKqmwofZ/vioSn+4kIaLXkeKvZ42w8SXksRuMpF2w0N5ONgCkpGaOdo gKEaPh9KIRnwloG4CqeuuXmL2cVoIAjROlaPsm+dc3ymOMk5U3abtsPwFn7RCGz71Z92 ePI5s/OJ3LKIOiVJbfvUCNXveatDuSJn/4caYVkzZV++Q6NdLDFPsZhX6VcbClqYATUe f15HtvTz/87QDiuEV4PSF1FBdni6lEfvShX9WHi8Yj9Es8chrGfBFEqmbaHgQl8cnEXz W97A== X-Forwarded-Encrypted: i=1; AJvYcCWq/oS6+dLRWZiecI3XgA/eD3ENlH1OgDyji3FhU6naI6S+EPGt9rl47JLCqw2fExdfrDcwxRj8yA==@kvack.org X-Gm-Message-State: AOJu0YxvMpcT7aSzzxW3jZztT9SMX2ombwM0teiMTxaVNkDeIco2LF1Z BjdAbOanVDlVO9xadqS2HxCqiEo8EnUzApRmw1jlo9RzxmZdKeNc2zd3UHBlxScwDo/9y5OyJqX vnfW+rex6+zYRyPEIow9w/4uA8iU= X-Google-Smtp-Source: AGHT+IH9tGGmzuoLdC+9FXy5dnBsaQ1Nkmre0QQV5rsQ+OMz1rCD3hlJDYfZvk0zaO5dBMltrkcDTbCLFOGk+jhleJY= X-Received: by 2002:a05:6512:e93:b0:535:6cef:ffb8 with SMTP id 2adb3069b0e04-5387756780cmr1158043e87.54.1727257740572; Wed, 25 Sep 2024 02:49:00 -0700 (PDT) MIME-Version: 1.0 References: <20240925081628.408-1-ebpqwerty472123@gmail.com> <64882dd5-5efd-4912-ab3d-0e6ee76380cf@lucifer.local> In-Reply-To: <64882dd5-5efd-4912-ab3d-0e6ee76380cf@lucifer.local> From: Shu Han Date: Wed, 25 Sep 2024 17:48:45 +0800 Message-ID: Subject: Re: [PATCH] mm: move security_file_mmap() back into do_mmap() To: Lorenzo Stoakes Cc: akpm@linux-foundation.org, paul@paul-moore.com, jmorris@namei.org, serge@hallyn.com, Liam.Howlett@oracle.com, vbabka@suse.cz, linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org, Al Viro Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Queue-Id: B61BF120014 X-Rspamd-Server: rspam01 X-Stat-Signature: ikg8te71d8pxe61yopmpg4znwgpqgbqp X-HE-Tag: 1727257742-73963 X-HE-Meta: U2FsdGVkX1+Fsn0YneyeDwtHW4qCPQe6kCBiDee6FN04jB9d2w8bQ4Y+TLgjPKzpcmdkbPdtX/ONtipWyx34fKDRCR2OqovfNg/R9zbBqovTfZks12vfxrxRlr71ULhbEQArkhv2lY8waUIsNKZ5iuGXiZIvEv9DInT/ttuKwRX6SNI1jP9STTauPUk0WDX9qq3vQX0dHFHWfTvnH0gprjGvjJSo9/bAL41Tj1uy8DSfVbjzFGRLxbp/D+mTtqLIwl+/nr2nG5zG2PBRhvvmaHbFWikscQ7LCeI3YZHeGYhGpeu4JEfZoJoqy3juoFWUcDnFl40FgbYbWHyppARz9VeFX/qZEiWY+Prbl2V5WnPJOMwHrjKWfORlMCMyEz31ZZrAvKl94JkzjxXYic1nh7/AeOX3qpyOUpPAHVszDX/vai4MvjKXKmkjfQE/llk1srTdJy8fNeh5WVWdBVM6aplhEMu2xOKssqfWlXNiSLj4QHAyrnewrZkpS7k1eDAqje9DG8E5IA8NOK1X3VlmcA73F+w+mdERTm497y1DcdMk9RmJ4FPnC8UDptCr3a9Y1MnIChD1QnKn86CzBT19i9RqFFElRKwIO6qLOEt98ykd08KT+v74n/pYQDnEmeVm6l8FAAGelGjhKv/EyYX3mR+JfItC/DVEsRxcGK/FhIse5iAR5QMhGGbFA2h5nhECNTn+lrupyNnVljBWpPevwJvorIL5JA4bdnEYj/hmCHTyofT5w7UklGPcdGBYEK8aBujBTj5DxIAS1wxPfgc1+eM6FPSuscIxwaWINkUJSl+mxEVvt3rCC8Q8vRs7pekkfsLepxT3/FyQWGPYtmRSXZqI/b8DRawrLWkikUwDFbw776a7XvkJ64qy6/FcK4T3t7b3jG9aisAD7bU27apKLMStochSohExUfQVZ2t4GPGLUhqJ9PlXTqjZi9+lvrAl3cB/hZc6oW0XfkwefvG 6WLRi6ej 1S07AN98VgyzZJCcEr288jR0KYD7nAYQ7P2amK+gfL3PvB3YNNehkNsbEtsoO7rAyQ4UCdy6U1C71ukxBsGDC07sb7QTil3qdTJmPb5plvVPjMz2jWGrqEW05g4v8dp79o27xEB/rdyAF2YrFpDM54fHkplnRpffaVqV58WcxxwSSqhusJlTmSeTvifNMAkdMnFDc0ReojCFU1MWsijyoiB75dquLEtBPYSVx58Beu+2xq752gFvU0FJQ/+YwNzYKCAP0LAz1y0qLFdu8xAxKfSzeT009hfmsPimBGlIvq2Ku+WAEsqfXWHomPGAjP9H3Ww/PaemjxM2lbU9g+uoHST6rPs7trnhhoob1TsYjinFo39+1QMADesEXHD6Bnp4OARfv2IyUTebIYc7NrcQCXhGgZSdxuZzaqX2AJZkHSg903MZr8kd8Mj4gk5Zdk1yrVlwNCifYhJ45iQP+Azs+I1AHRIPShRWBOn2hAn24xGa4qxFaYkyLCf3P4rR2kcr4YbJIfXpCiAdEx5E= 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: List-Subscribe: List-Unsubscribe: TL;DR: Thanks for the sugguestions in format. But for actual content, it ma= y be more appropriate to read it in its entirety first. > TL;DR: NACK because you sent two conflicting non-RFC patches as > 'alternatives', which is not how development on-list works. Please resend > maybe one of these as an RFC... > > +Al into this as he is the author of commit 8b3ec6814c83. > You can't send multiple conflicting non-RFC patches at once... that's > completely ridiculous. > > NACK, and re-send one of these as an RFC perhaps referencing the other as > an alternative? I am very sorry that I sent the wrong subject which should add "RFC", due to lack of experience. > On Wed, Sep 25, 2024 at 04:16:28PM GMT, Shu Han wrote: > > This patch moves the security_file_mmap() back into do_mmap(), which > > revert the commit 8b3ec6814c83d76b85bd13badc48552836c24839 > > ("take security_mmap_file() outside of ->mmap_sem"). Below is the reaso= n. > > Nit - we typically use the short version of the commit hash when > referencing a commit, so this would be commit 8b3ec6814c83. Thanks for the correct of format. > Also if this is a revert this should be reflected in the subject... and > presumably given the original patch is from 2012 it's not a revert at all= ? It is conceptually a revert of the commit(revert the feature change in the commit), but not in the git sense(revert the lines of code). > 'Some logic'? Which? The next paragraph provides corresponding examples. > There's no security_file_mmap() function in the kernel? You mean > security_mmap_file()? You're attempting to do something pretty major here= , > so while this is obviously a typo it's pretty important you get these > details right :) Thanks for the correct. In fact, this is copied from others reply. > But we might want to do things internal to the kernel that don't require > this check? Drivers can map too - the only place we need to be doing the > security check is in the user-facing mmap syscall. > > If something is added that calls do_mmap() without proper security checks= - > that's a bug in _that_ interface. > > So I disagree with this patch as a whole. > > Keep in mind we _do_ perform a security-hooked free memory check in the > mmap logic security_vm_enough_memory_mm(), so it isn't as if everything i= s > bypassed, only this security_mmap_file() function. > > Which is surely only applicable in instances of user-facing API so is... = in > the right place now? > > Yeah I am not convinced on any level. Bypass security_mmap_file() is enough for an attack for SELinux. As with the position of security_vm_enough_memory_mm(), the LSM hook must be placed in a __internal__ position to avoid bypassing as mentioned in the two examples, which can lead to serious security issues. SELinx and many other mandatory access controls(MAC) rely on LSM hooks. MAC is not a shallow interception of user-facing like seccomp, it is __not__ a DAC. In fact, SELinux also restricts some internal behaviors of the kernel (the SELinux label for the kernel is usually `u:r:kernel:s0` ). Yes, in the sense of DAC, the kernel certainly has full permission. But MAC must prevent user space code implicitly triggering the internal behavior of the kernel, which can be expolit by attackers. Do such a change is also suggested by LSM maintainer in the fix of [1]. > > It is noteworthy that moving the security check in do_mmap() will let i= t > > in the mmap_write_lock, which slows down the performance and even have > > deadlocks if someone depends on it(Since security_file_mprotect() is > > already in the lock, this possibility is tiny). > > Err what? We can't accept a patch that might deadlock even if you claim t= he > possibility is 'tiny'... that's a NACK in itself. You _have_ to demonstra= te > that you aren't deadlocking, this isn't optional. Yes, this patch should be marked as a RFC, not request for merge immediatel= y. > > Link: https://project-zero.issues.chromium.org/issues/42452389 [1] > > Link: https://lore.kernel.org/all/20240919080905.4506-2-paul@paul-moore= .com/ [2] > > Signed-off-by: Shu Han > > You need to have a fixes tag here for Al's patch presumably. This is not a fix for these two links, but a further measure taken to avoid= the recurrence of such fixed issues. > Err.... why are we removing all of this?? This is mentioned in patch. > > Moving security_file_mmap() back into do_mmap() can avoid > > forgetting, and avoid __repeated__ logic for whether READ_IMPLIES_EXEC = should > > add PROT_EXEC for the mapping or not(In current, the !MMU case won't > > imply exec if the file's mmap_capabilities is not exist, but the > > security check logic is different). Link: https://lore.kernel.org/all/20240919080905.4506-2-paul@paul-moore.com= / [1] Lorenzo Stoakes =E4=BA=8E2024=E5=B9=B49=E6=9C= =8825=E6=97=A5=E5=91=A8=E4=B8=89 16:44=E5=86=99=E9=81=93=EF=BC=9A > > TL;DR: NACK because you sent two conflicting non-RFC patches as > 'alternatives', which is not how development on-list works. Please resend > maybe one of these as an RFC... > > +Al into this as he is the author of commit 8b3ec6814c83. > > > On Wed, Sep 25, 2024 at 04:16:28PM GMT, Shu Han wrote: > > This patch moves the security_file_mmap() back into do_mmap(), which > > revert the commit 8b3ec6814c83d76b85bd13badc48552836c24839 > > ("take security_mmap_file() outside of ->mmap_sem"). Below is the reaso= n. > > Nit - we typically use the short version of the commit hash when > referencing a commit, so this would be commit 8b3ec6814c83. > > Also if this is a revert this should be reflected in the subject... and > presumably given the original patch is from 2012 it's not a revert at all= ? > > > > > Some logic may call do_mmap() without calling security_file_mmap(), > > without being aware of the harm this poses to LSM. > > 'Some logic'? Which? > > There's no security_file_mmap() function in the kernel? You mean > security_mmap_file()? You're attempting to do something pretty major here= , > so while this is obviously a typo it's pretty important you get these > details right :) > > > > > For example, CVE-2016-10044[1] has reported many years ago, but the > > remap_file_pages() can still bypass the W^X policy enforced by SELinux[= 2] > > for a long time. > > > > Add a check is easy, but there may have more calls to do_mmap() in the > > future. Moving security_file_mmap() back into do_mmap() can avoid > > forgetting, and avoid repeated logic for whether READ_IMPLIES_EXEC shou= ld > > add PROT_EXEC for the mapping or not(In current, the !MMU case won't > > imply exec if the file's mmap_capabilities is not exist, but the > > security check logic is different). > > But we might want to do things internal to the kernel that don't require > this check? Drivers can map too - the only place we need to be doing the > security check is in the user-facing mmap syscall. > > If something is added that calls do_mmap() without proper security checks= - > that's a bug in _that_ interface. > > So I disagree with this patch as a whole. > > Keep in mind we _do_ perform a security-hooked free memory check in the > mmap logic security_vm_enough_memory_mm(), so it isn't as if everything i= s > bypassed, only this security_mmap_file() function. > > Which is surely only applicable in instances of user-facing API so is... = in > the right place now? > > Yeah I am not convinced on any level. > > > > > It is noteworthy that moving the security check in do_mmap() will let i= t > > in the mmap_write_lock, which slows down the performance and even have > > deadlocks if someone depends on it(Since security_file_mprotect() is > > already in the lock, this possibility is tiny). > > Err what? We can't accept a patch that might deadlock even if you claim t= he > possibility is 'tiny'... that's a NACK in itself. You _have_ to demonstra= te > that you aren't deadlocking, this isn't optional. > > > > > Link: https://project-zero.issues.chromium.org/issues/42452389 [1] > > Link: https://lore.kernel.org/all/20240919080905.4506-2-paul@paul-moore= .com/ [2] > > Signed-off-by: Shu Han > > You need to have a fixes tag here for Al's patch presumably. > > > --- > > An alternative method is moving the check of READ_IMPLIES_EXEC out of > > do_mmap() and calling the LSM hooks at the same time, which has better > > performance and compatibility but may introduce some complexity. It has > > been proposed in [3], which cannot be applied at the same time with > > this patch. > > Link: https://lore.kernel.org/all/20240925063034.169-1-ebpqwerty472123@= gmail.com/ [3] > > You can't send multiple conflicting non-RFC patches at once... that's > completely ridiculous. > > NACK, and re-send one of these as an RFC perhaps referencing the other as > an alternative? > > > --- > > include/linux/security.h | 8 ++++---- > > ipc/shm.c | 4 ---- > > mm/mmap.c | 9 +++++---- > > mm/nommu.c | 5 ++++- > > mm/util.c | 19 ++++++++----------- > > security/security.c | 41 ++++------------------------------------ > > 6 files changed, 25 insertions(+), 61 deletions(-) > > > > diff --git a/include/linux/security.h b/include/linux/security.h > > index c37c32ebbdcd..e061bc9a0331 100644 > > --- a/include/linux/security.h > > +++ b/include/linux/security.h > > @@ -423,8 +423,8 @@ void security_file_free(struct file *file); > > int security_file_ioctl(struct file *file, unsigned int cmd, unsigned = long arg); > > int security_file_ioctl_compat(struct file *file, unsigned int cmd, > > unsigned long arg); > > -int security_mmap_file(struct file *file, unsigned long prot, > > - unsigned long flags); > > +int security_mmap_file(struct file *file, unsigned long reqprot, > > + unsigned long prot, unsigned long flags); > > int security_mmap_addr(unsigned long addr); > > int security_file_mprotect(struct vm_area_struct *vma, unsigned long r= eqprot, > > unsigned long prot); > > @@ -1077,8 +1077,8 @@ static inline int security_file_ioctl_compat(stru= ct file *file, > > return 0; > > } > > > > -static inline int security_mmap_file(struct file *file, unsigned long = prot, > > - unsigned long flags) > > +static inline int security_mmap_file(struct file *file, unsigned long = reqprot, > > + unsigned long prot, unsigned long fl= ags) > > { > > return 0; > > } > > diff --git a/ipc/shm.c b/ipc/shm.c > > index 3e3071252dac..ce02560b856f 100644 > > --- a/ipc/shm.c > > +++ b/ipc/shm.c > > @@ -1636,10 +1636,6 @@ long do_shmat(int shmid, char __user *shmaddr, i= nt shmflg, > > sfd->vm_ops =3D NULL; > > file->private_data =3D sfd; > > > > - err =3D security_mmap_file(file, prot, flags); > > - if (err) > > - goto out_fput; > > - > > if (mmap_write_lock_killable(current->mm)) { > > err =3D -EINTR; > > goto out_fput; > > diff --git a/mm/mmap.c b/mm/mmap.c > > index 18fddcce03b8..56f9520f85ab 100644 > > --- a/mm/mmap.c > > +++ b/mm/mmap.c > > @@ -1260,6 +1260,7 @@ unsigned long do_mmap(struct file *file, unsigned= long addr, > > { > > struct mm_struct *mm =3D current->mm; > > int pkey =3D 0; > > + unsigned long reqprot =3D prot, err; > > > > *populate =3D 0; > > > > @@ -1276,6 +1277,10 @@ unsigned long do_mmap(struct file *file, unsigne= d long addr, > > if (!(file && path_noexec(&file->f_path))) > > prot |=3D PROT_EXEC; > > > > + err =3D security_mmap_file(file, reqprot, prot, flags); > > + if (err) > > + return err; > > + > > /* force arch specific MAP_FIXED handling in get_unmapped_area */ > > if (flags & MAP_FIXED_NOREPLACE) > > flags |=3D MAP_FIXED; > > @@ -3198,12 +3203,8 @@ SYSCALL_DEFINE5(remap_file_pages, unsigned long,= start, unsigned long, size, > > flags |=3D MAP_LOCKED; > > > > file =3D get_file(vma->vm_file); > > - ret =3D security_mmap_file(vma->vm_file, prot, flags); > > - if (ret) > > - goto out_fput; > > ret =3D do_mmap(vma->vm_file, start, size, > > prot, flags, 0, pgoff, &populate, NULL); > > -out_fput: > > fput(file); > > out: > > mmap_write_unlock(mm); > > diff --git a/mm/nommu.c b/mm/nommu.c > > index 7296e775e04e..e632f3105a5a 100644 > > --- a/mm/nommu.c > > +++ b/mm/nommu.c > > @@ -681,7 +681,7 @@ static int validate_mmap_request(struct file *file, > > unsigned long pgoff, > > unsigned long *_capabilities) > > { > > - unsigned long capabilities, rlen; > > + unsigned long capabilities, rlen, reqprot =3D prot; > > int ret; > > > > /* do the simple checks first */ > > @@ -818,6 +818,9 @@ static int validate_mmap_request(struct file *file, > > } > > > > /* allow the security API to have its say */ > > + ret =3D security_mmap_file(file, reqprot, prot, flags); > > + if (ret < 0) > > + return ret; > > ret =3D security_mmap_addr(addr); > > if (ret < 0) > > return ret; > > diff --git a/mm/util.c b/mm/util.c > > index bd283e2132e0..47345e927a8f 100644 > > --- a/mm/util.c > > +++ b/mm/util.c > > @@ -581,17 +581,14 @@ unsigned long vm_mmap_pgoff(struct file *file, un= signed long addr, > > unsigned long populate; > > LIST_HEAD(uf); > > > > - ret =3D security_mmap_file(file, prot, flag); > > - if (!ret) { > > - if (mmap_write_lock_killable(mm)) > > - return -EINTR; > > - ret =3D do_mmap(file, addr, len, prot, flag, 0, pgoff, &p= opulate, > > - &uf); > > - mmap_write_unlock(mm); > > - userfaultfd_unmap_complete(mm, &uf); > > - if (populate) > > - mm_populate(ret, populate); > > - } > > + if (mmap_write_lock_killable(mm)) > > + return -EINTR; > > + ret =3D do_mmap(file, addr, len, prot, flag, 0, pgoff, &populate, > > + &uf); > > + mmap_write_unlock(mm); > > + userfaultfd_unmap_complete(mm, &uf); > > + if (populate) > > + mm_populate(ret, populate); > > return ret; > > } > > > > diff --git a/security/security.c b/security/security.c > > index 4564a0a1e4ef..25556629f588 100644 > > --- a/security/security.c > > +++ b/security/security.c > > @@ -2927,42 +2927,10 @@ int security_file_ioctl_compat(struct file *fil= e, unsigned int cmd, > > } > > EXPORT_SYMBOL_GPL(security_file_ioctl_compat); > > > > -static inline unsigned long mmap_prot(struct file *file, unsigned long= prot) > > -{ > > - /* > > - * Does we have PROT_READ and does the application expect > > - * it to imply PROT_EXEC? If not, nothing to talk about... > > - */ > > - if ((prot & (PROT_READ | PROT_EXEC)) !=3D PROT_READ) > > - return prot; > > - if (!(current->personality & READ_IMPLIES_EXEC)) > > - return prot; > > - /* > > - * if that's an anonymous mapping, let it. > > - */ > > - if (!file) > > - return prot | PROT_EXEC; > > - /* > > - * ditto if it's not on noexec mount, except that on !MMU we need > > - * NOMMU_MAP_EXEC (=3D=3D VM_MAYEXEC) in this case > > - */ > > - if (!path_noexec(&file->f_path)) { > > -#ifndef CONFIG_MMU > > - if (file->f_op->mmap_capabilities) { > > - unsigned caps =3D file->f_op->mmap_capabilities(f= ile); > > - if (!(caps & NOMMU_MAP_EXEC)) > > - return prot; > > - } > > -#endif > > - return prot | PROT_EXEC; > > - } > > - /* anything on noexec mount won't get PROT_EXEC */ > > - return prot; > > -} > > - > > Err.... why are we removing all of this?? > > > /** > > * security_mmap_file() - Check if mmap'ing a file is allowed > > * @file: file > > + * @reqprot: protection requested by user > > * @prot: protection applied by the kernel > > * @flags: flags > > * > > @@ -2971,11 +2939,10 @@ static inline unsigned long mmap_prot(struct fi= le *file, unsigned long prot) > > * > > * Return: Returns 0 if permission is granted. > > */ > > -int security_mmap_file(struct file *file, unsigned long prot, > > - unsigned long flags) > > +int security_mmap_file(struct file *file, unsigned long reqprot, > > + unsigned long prot, unsigned long flags) > > { > > - return call_int_hook(mmap_file, file, prot, mmap_prot(file, prot)= , > > - flags); > > + return call_int_hook(mmap_file, file, reqprot, prot, flags); > > } > > > > /** > > > > base-commit: f89722faa31466ff41aed21bdeb9cf34c2312858 > > -- > > 2.34.1 > >