mm/vma.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
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>
---
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
On 12/6/24 22:52, Lorenzo Stoakes wrote:
> 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()")
FFS, who reviewed that patch?
> Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Reviewed-by: Vlastimil Babka <vbabka@suse.cz>
(copy/pasted from "git show 5ac87a885aec")
> ---
> 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
* 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.
Reviewed-by: Liam R. Howlett <Liam.Howlett@Oracle.com>
> ---
> 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
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
Andrew - sorry, I forgot to put a subject-prefix in here - we need this as
a (fairly urgent) hotfix for 6.13 please.
Thanks!
On Fri, Dec 06, 2024 at 09:52:29PM +0000, Lorenzo Stoakes wrote:
> 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>
> ---
> 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
© 2016 - 2025 Red Hat, Inc.