All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chengguang Xu <cgxu519@mykernel.net>
To: "Miklos Szeredi" <miklos@szeredi.hu>
Cc: linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	linux-mm <linux-mm@kvack.org>,
	"\"Christian König\"" <ckoenig.leichtzumerken@gmail.com>,
	linux-unionfs <linux-unionfs@vger.kernel.org>
Subject: 回复:[PATCH] ovl: fix mmap denywrite
Date: Wed, 23 Jun 2021 14:06:13 +0800	[thread overview]
Message-ID: <17a3779e6d8.10898dfd28835.4753809433352490949@mykernel.net> (raw)
In-Reply-To: <YNHXzBgzRrZu1MrD@miu.piliscsaba.redhat.com>

 ---- 在 星期二, 2021-06-22 20:30:04 Miklos Szeredi <miklos@szeredi.hu> 撰写 ----
 > Overlayfs did not honor positive i_writecount on realfile for VM_DENYWRITE
 > mappings.  Similarly negative i_mmap_writable counts were ignored for
 > VM_SHARED mappings.
 > 
 > Fix by making vma_set_file() switch the temporary counts obtained and
 > released by mmap_region().
 > 
 > Reported-by: Chengguang Xu <cgxu519@mykernel.net>
 > Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
 > ---
 >  fs/overlayfs/file.c |    4 +++-
 >  include/linux/mm.h  |    1 +
 >  mm/mmap.c           |    2 +-
 >  mm/util.c           |   38 +++++++++++++++++++++++++++++++++++++-
 >  4 files changed, 42 insertions(+), 3 deletions(-)
 > 
 > --- a/fs/overlayfs/file.c
 > +++ b/fs/overlayfs/file.c
 > @@ -430,7 +430,9 @@ static int ovl_mmap(struct file *file, s
 >      if (WARN_ON(file != vma->vm_file))
 >          return -EIO;
 >  
 > -    vma_set_file(vma, realfile);
 > +    ret = vma_set_file_checkwrite(vma, realfile);
 > +    if (ret)
 > +        return ret;

I'm afraid that it may affect other overlayfs instances which share lower layers(no upper),
so could we just check those permissions for upper layer?



 >  
 >      old_cred = ovl_override_creds(file_inode(file)->i_sb);
 >      ret = call_mmap(vma->vm_file, vma);
 > --- a/include/linux/mm.h
 > +++ b/include/linux/mm.h
 > @@ -2751,6 +2751,7 @@ static inline void vma_set_page_prot(str
 >  #endif
 >  
 >  void vma_set_file(struct vm_area_struct *vma, struct file *file);
 > +int vma_set_file_checkwrite(struct vm_area_struct *vma, struct file *file);
 >  
 >  #ifdef CONFIG_NUMA_BALANCING
 >  unsigned long change_prot_numa(struct vm_area_struct *vma,
 > --- a/mm/mmap.c
 > +++ b/mm/mmap.c
 > @@ -1809,6 +1809,7 @@ unsigned long mmap_region(struct file *f
 >           */
 >          vma->vm_file = get_file(file);
 >          error = call_mmap(file, vma);
 > +        file = vma->vm_file;


I'm not sure the behavior of changing vma_file is always safe for vma merging case.
In vma merging case, before go to tag 'unmap_writable' the reference of vma->vm_file will be released by fput().
For overlayfs, it probably safe because overlayfs file will get another reference for lower/upper file.



Thanks,
Chengguang Xu




 >          if (error)
 >              goto unmap_and_free_vma;
 >  
 > @@ -1870,7 +1871,6 @@ unsigned long mmap_region(struct file *f
 >          if (vm_flags & VM_DENYWRITE)
 >              allow_write_access(file);
 >      }
 > -    file = vma->vm_file;
 >  out:
 >      perf_event_mmap(vma);
 >  
 > --- a/mm/util.c
 > +++ b/mm/util.c
 > @@ -314,12 +314,48 @@ int vma_is_stack_for_current(struct vm_a
 >  /*
 >   * Change backing file, only valid to use during initial VMA setup.
 >   */
 > -void vma_set_file(struct vm_area_struct *vma, struct file *file)
 > +int vma_set_file_checkwrite(struct vm_area_struct *vma, struct file *file)
 >  {
 > +    vm_flags_t vm_flags = vma->vm_flags;
 > +    int err = 0;
 > +
 >      /* Changing an anonymous vma with this is illegal */
 >      get_file(file);
 > +
 > +    /* Get temporary denial counts on replacement */
 > +    if (vm_flags & VM_DENYWRITE) {
 > +        err = deny_write_access(file);
 > +        if (err)
 > +            goto out_put;
 > +    }
 > +    if (vm_flags & VM_SHARED) {
 > +        err = mapping_map_writable(file->f_mapping);
 > +        if (err)
 > +            goto out_allow;
 > +    }
 > +
 >      swap(vma->vm_file, file);
 > +
 > +    /* Undo temporary denial counts on replaced */
 > +    if (vm_flags & VM_SHARED)
 > +        mapping_unmap_writable(file->f_mapping);
 > +out_allow:
 > +    if (vm_flags & VM_DENYWRITE)
 > +        allow_write_access(file);
 > +out_put:
 >      fput(file);
 > +    return err;
 > +}
 > +EXPORT_SYMBOL(vma_set_file_checkwrite);
 > +
 > +/*
 > + * Change backing file, only valid to use during initial VMA setup.
 > + */
 > +void vma_set_file(struct vm_area_struct *vma, struct file *file)
 > +{
 > +    int err = vma_set_file_checkwrite(vma, file);
 > +
 > +    WARN_ON_ONCE(err);
 >  }
 >  EXPORT_SYMBOL(vma_set_file);
 >  
 > 
 > 
 > 

      parent reply	other threads:[~2021-06-23  6:06 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-22 12:30 [PATCH] ovl: fix mmap denywrite Miklos Szeredi
2021-06-22 12:43 ` Christian König
2021-06-22 15:10   ` Miklos Szeredi
2021-06-22 15:10     ` Miklos Szeredi
2021-06-23 11:41     ` Christian König
2021-07-09 13:48       ` Miklos Szeredi
2021-07-12 11:15         ` Christian König
2021-06-23  6:06 ` Chengguang Xu [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=17a3779e6d8.10898dfd28835.4753809433352490949@mykernel.net \
    --to=cgxu519@mykernel.net \
    --cc=ckoenig.leichtzumerken@gmail.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-unionfs@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.