linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
To: "Liam R. Howlett" <Liam.Howlett@oracle.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Vlastimil Babka <vbabka@suse.cz>, Jann Horn <jannh@google.com>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm: correctly reference merged VMA
Date: Mon, 9 Dec 2024 11:02:51 +0000	[thread overview]
Message-ID: <6d8f9fd9-5735-4285-b7db-9d8c1bf58c95@lucifer.local> (raw)
In-Reply-To: <qvsozunpi4yvooov4usji4xu3v2dt52f3mxcwkwtdcywu6xpgb@oald6acxjrui>

On Fri, Dec 06, 2024 at 05:40:39PM -0500, Liam R. Howlett wrote:
> * Lorenzo Stoakes <lorenzo.stoakes@oracle.com> [241206 16:52]:
> > On second merge attempt on mmap() we incorrectly discard the possibly
> > merged VMA, resulting in a possible use-after-free (and most certainly a
> > reference to the wrong VMA) in this instance in the subsequent
> > __mmap_complete() invocation.
> >
> > Correct this mistake by reassigning vma correctly if a merge succeeds in
> > this case.
> >
> > Suggested-by: Jann Horn <jannh@google.com>
> > Reported-by: syzbot+91cf8da9401355f946c3@syzkaller.appspotmail.com
> > Closes: https://lore.kernel.org/all/67536a25.050a0220.a30f1.0149.GAE@google.com/
> > Fixes: 5ac87a885aec ("mm: defer second attempt at merge on mmap()")
> > Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
>
> My cries to delete this optimisation continue.

I'd love to too, but it does seem that has an important use in that you get a
file system/driver that sets certain VMA flags.

So you have:

         [  VMA B  ] <- map
[ VMA A ] < space > [ VMA C ]

Merge attempt #1 - missing VM_xxx that is set by f_op->mmap() hook
Merge attempt #2 - succeed because VM_xxx is set.

This, I think, speaks to the need to provide a means by which
filesystems/drivers can manipulate VMA flags _up front_. At which point we can
eliminate this.

I mean as you say this is an -optimisation- and having split VMAs will work fine
(modulo mremap weirdness), but because of the above it becomes possible for
there to be a major proliferation of unneeded VMAs, so it's not quite as much of
a fringe thing as it might appear to be.

I mean we can also talk about the fact that there's logic in __mmap_complete()
that clears VM_LOCKED | VM_LOCKONFAULT under certain circumstances which is just
not considered for merging at all but... yeah. That is, at least, much less
likely.

>
> Reviewed-by: Liam R. Howlett <Liam.Howlett@Oracle.com>

Thanks :)

>
> > ---
> >  mm/vma.c | 5 ++++-
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/mm/vma.c b/mm/vma.c
> > index 8a454a7bbc80..1ec349141f5e 100644
> > --- a/mm/vma.c
> > +++ b/mm/vma.c
> > @@ -2460,10 +2460,13 @@ unsigned long __mmap_region(struct file *file, unsigned long addr,
> >
> >  	/* If flags changed, we might be able to merge, so try again. */
> >  	if (map.retry_merge) {
> > +		struct vm_area_struct *merged;
> >  		VMG_MMAP_STATE(vmg, &map, vma);
> >
> >  		vma_iter_config(map.vmi, map.addr, map.end);
> > -		vma_merge_existing_range(&vmg);
> > +		merged = vma_merge_existing_range(&vmg);
> > +		if (merged)
> > +			vma = merged;
> >  	}
> >
> >  	__mmap_complete(&map, vma);
> > --
> > 2.47.1


  reply	other threads:[~2024-12-09 11:03 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-06 21:52 Lorenzo Stoakes
2024-12-06 21:55 ` Lorenzo Stoakes
2024-12-06 22:40 ` Liam R. Howlett
2024-12-09 11:02   ` Lorenzo Stoakes [this message]
2024-12-09 13:19 ` Vlastimil Babka

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=6d8f9fd9-5735-4285-b7db-9d8c1bf58c95@lucifer.local \
    --to=lorenzo.stoakes@oracle.com \
    --cc=Liam.Howlett@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=jannh@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=vbabka@suse.cz \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox