| Message ID | 20220516125405.1675-3-matenajakub@gmail.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | Removing limitations of merging anonymous VMAs | expand |
On Mon, May 16, 2022 at 02:54:01PM +0200, Jakub Matěna wrote: > When mremap call results in expansion, it might be possible to merge the > VMA with the next VMA which might become adjacent. This patch adds > vma_merge call after the expansion is done to try and merge. > > Signed-off-by: Jakub Matěna <matenajakub@gmail.com> > --- > mm/mremap.c | 7 +++++-- > 1 file changed, 5 insertions(+), 2 deletions(-) > > diff --git a/mm/mremap.c b/mm/mremap.c > index 303d3290b938..75cda854ec58 100644 > --- a/mm/mremap.c > +++ b/mm/mremap.c > @@ -9,6 +9,7 @@ > */ > > #include <linux/mm.h> > +#include <linux/mm_inline.h> > #include <linux/hugetlb.h> > #include <linux/shm.h> > #include <linux/ksm.h> > @@ -1022,8 +1023,10 @@ SYSCALL_DEFINE5(mremap, unsigned long, addr, unsigned long, old_len, > } > } > > - if (vma_adjust(vma, vma->vm_start, addr + new_len, > - vma->vm_pgoff, NULL)) { > + if (!vma_merge(mm, vma, addr + old_len, addr + new_len, > + vma->vm_flags, vma->anon_vma, vma->vm_file, > + vma->vm_pgoff + (old_len >> PAGE_SHIFT), vma_policy(vma), > + vma->vm_userfaultfd_ctx, anon_vma_name(vma))) { Hm. Don't you need to update 'vma' with result of vma_merge()? 'vma' is used below the point and IIUC it can be use-after-free.
On Fri, May 20, 2022 at 3:39 PM Kirill A. Shutemov <kirill@shutemov.name> wrote: > > On Mon, May 16, 2022 at 02:54:01PM +0200, Jakub Matěna wrote: > > When mremap call results in expansion, it might be possible to merge the > > VMA with the next VMA which might become adjacent. This patch adds > > vma_merge call after the expansion is done to try and merge. > > > > Signed-off-by: Jakub Matěna <matenajakub@gmail.com> > > --- > > mm/mremap.c | 7 +++++-- > > 1 file changed, 5 insertions(+), 2 deletions(-) > > > > diff --git a/mm/mremap.c b/mm/mremap.c > > index 303d3290b938..75cda854ec58 100644 > > --- a/mm/mremap.c > > +++ b/mm/mremap.c > > @@ -9,6 +9,7 @@ > > */ > > > > #include <linux/mm.h> > > +#include <linux/mm_inline.h> > > #include <linux/hugetlb.h> > > #include <linux/shm.h> > > #include <linux/ksm.h> > > @@ -1022,8 +1023,10 @@ SYSCALL_DEFINE5(mremap, unsigned long, addr, unsigned long, old_len, > > } > > } > > > > - if (vma_adjust(vma, vma->vm_start, addr + new_len, > > - vma->vm_pgoff, NULL)) { > > + if (!vma_merge(mm, vma, addr + old_len, addr + new_len, > > + vma->vm_flags, vma->anon_vma, vma->vm_file, > > + vma->vm_pgoff + (old_len >> PAGE_SHIFT), vma_policy(vma), > > + vma->vm_userfaultfd_ctx, anon_vma_name(vma))) { > > Hm. Don't you need to update 'vma' with result of vma_merge()? > > 'vma' is used below the point and IIUC it can be use-after-free. > Actually, this merge call is always either case 1 or 2 as they are defined in the vma_merge(). So, either way the 'vma' can absorb its neighbors but never gets absorbed itself. But you are right and I will add the update, because otherwise it would depend on the vma_merge() implementation, which could possibly change in the future and cause a bug. > -- > Kirill A. Shutemov
diff --git a/mm/mremap.c b/mm/mremap.c index 303d3290b938..75cda854ec58 100644 --- a/mm/mremap.c +++ b/mm/mremap.c @@ -9,6 +9,7 @@ */ #include <linux/mm.h> +#include <linux/mm_inline.h> #include <linux/hugetlb.h> #include <linux/shm.h> #include <linux/ksm.h> @@ -1022,8 +1023,10 @@ SYSCALL_DEFINE5(mremap, unsigned long, addr, unsigned long, old_len, } } - if (vma_adjust(vma, vma->vm_start, addr + new_len, - vma->vm_pgoff, NULL)) { + if (!vma_merge(mm, vma, addr + old_len, addr + new_len, + vma->vm_flags, vma->anon_vma, vma->vm_file, + vma->vm_pgoff + (old_len >> PAGE_SHIFT), vma_policy(vma), + vma->vm_userfaultfd_ctx, anon_vma_name(vma))) { vm_unacct_memory(pages); ret = -ENOMEM; goto out;
When mremap call results in expansion, it might be possible to merge the VMA with the next VMA which might become adjacent. This patch adds vma_merge call after the expansion is done to try and merge. Signed-off-by: Jakub Matěna <matenajakub@gmail.com> --- mm/mremap.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-)