[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Z1NjgK2wSUdeM525@google.com>
Date: Fri, 6 Dec 2024 12:50:08 -0800
From: Isaac Manjarres <isaacmanjarres@...gle.com>
To: Kalesh Singh <kaleshsingh@...gle.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Jeff Layton <jlayton@...nel.org>,
Chuck Lever <chuck.lever@...cle.com>,
Alexander Aring <alex.aring@...il.com>,
"Liam R. Howlett" <Liam.Howlett@...cle.com>,
Lorenzo Stoakes <lorenzo.stoakes@...cle.com>,
Vlastimil Babka <vbabka@...e.cz>, Jann Horn <jannh@...gle.com>,
Shuah Khan <shuah@...nel.org>, kernel-team@...roid.com,
linux-mm@...ck.org, linux-kernel@...r.kernel.org,
linux-fsdevel@...r.kernel.org, linux-kselftest@...r.kernel.org,
Suren Baghdasaryan <surenb@...gle.com>,
John Stultz <jstultz@...gle.com>
Subject: Re: [RFC PATCH v1 1/2] mm/memfd: Add support for F_SEAL_FUTURE_EXEC
to memfd
On Fri, Dec 06, 2024 at 09:49:35AM -0800, Kalesh Singh wrote:
> On Thu, Dec 5, 2024 at 5:09 PM Isaac J. Manjarres
> <isaacmanjarres@...gle.com> wrote:
> > --- a/mm/mmap.c
> > +++ b/mm/mmap.c
> > @@ -375,6 +375,17 @@ unsigned long do_mmap(struct file *file, unsigned long addr,
> > if (!file_mmap_ok(file, inode, pgoff, len))
> > return -EOVERFLOW;
> >
> > + if (is_exec_sealed(seals)) {
> > + /* No new executable mappings if the file is exec sealed. */
> > + if (prot & PROT_EXEC)
> > + return -EACCES;
>
> I think this should be -EPERM to be consistent with seal_check_write()
> and mmap(2) man page:
>
> " EPERM The operation was prevented by a file seal; see fcntl(2)."
>
> Thanks,
> Kalesh
>
Thanks for catching that Kalesh! I agree and will fix this in v2 of the
series.
Thanks,
Isaac
Powered by blists - more mailing lists