linux-kernel - Re: [PATCH v7 06/17] mm/nommu: fix the last places where vma is not locked before being attached

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAJuCfpFXuZq5YVW2fzFnnmLbpB9Gqn2M98b3Ds5LEhmB2MDzrQ@mail.gmail.com>
Date: Tue, 7 Jan 2025 10:05:22 -0800
From: Suren Baghdasaryan <surenb@...gle.com>
To: "Liam R. Howlett" <Liam.Howlett@...cle.com>, Suren Baghdasaryan <surenb@...gle.com>, 
	akpm@...ux-foundation.org, peterz@...radead.org, willy@...radead.org, 
	lorenzo.stoakes@...cle.com, mhocko@...e.com, vbabka@...e.cz, 
	hannes@...xchg.org, mjguzik@...il.com, oliver.sang@...el.com, 
	mgorman@...hsingularity.net, david@...hat.com, peterx@...hat.com, 
	oleg@...hat.com, dave@...olabs.net, paulmck@...nel.org, brauner@...nel.org, 
	dhowells@...hat.com, hdanton@...a.com, hughd@...gle.com, 
	lokeshgidra@...gle.com, minchan@...gle.com, jannh@...gle.com, 
	shakeel.butt@...ux.dev, souravpanda@...gle.com, pasha.tatashin@...een.com, 
	klarasmodin@...il.com, corbet@....net, linux-doc@...r.kernel.org, 
	linux-mm@...ck.org, linux-kernel@...r.kernel.org, kernel-team@...roid.com
Subject: Re: [PATCH v7 06/17] mm/nommu: fix the last places where vma is not
 locked before being attached

On Tue, Jan 7, 2025 at 9:51 AM Liam R. Howlett <Liam.Howlett@...cle.com> wrote:
>
> * Suren Baghdasaryan <surenb@...gle.com> [241226 12:07]:
> > nommu configuration has two places where vma gets attached to the vma tree
> > without write-locking it. Add the missing locks to ensure vma is always
> > locked before it's attached.
>
> Does the delete side need to write lock as well?

Ugh. I just realized that CONFIG_PER_VMA_LOCK depends on CONFIG_MMU,
so this patch is not needed because all these per-vma functions are
NoOps when CONFIG_PER_VMA_LOCK=n. I'll drop it in the next version.

>
> >
> > Signed-off-by: Suren Baghdasaryan <surenb@...gle.com>
> > ---
> >  mm/nommu.c | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/mm/nommu.c b/mm/nommu.c
> > index 72c8c505836c..1754e84e5758 100644
> > --- a/mm/nommu.c
> > +++ b/mm/nommu.c
> > @@ -1189,6 +1189,7 @@ unsigned long do_mmap(struct file *file,
> >               goto error_just_free;
> >
> >       setup_vma_to_mm(vma, current->mm);
> > +     vma_start_write(vma);
> >       current->mm->map_count++;
> >       /* add the VMA to the tree */
> >       vma_iter_store(&vmi, vma, true);
> > @@ -1356,6 +1357,7 @@ static int split_vma(struct vma_iterator *vmi, struct vm_area_struct *vma,
> >
> >       setup_vma_to_mm(vma, mm);
> >       setup_vma_to_mm(new, mm);
> > +     vma_start_write(new);
> >       vma_iter_store(vmi, new, true);
> >       mm->map_count++;
> >       return 0;
> > --
> > 2.47.1.613.gc27f4b7a9f-goog
> >