Re: [PATCH 1/1] mm: fix a UAF when vma->mm is freed after vma->vm_refcnt got dropped

[Suren Baghdasaryan <surenb@google.com>]

On Mon, Jul 28, 2025 at 10:43 AM Suren Baghdasaryan <surenb@google.com> wrote:
>
> On Mon, Jul 28, 2025 at 10:39 AM Vlastimil Babka <vbabka@suse.cz> wrote:
> >
> > On 7/28/25 19:37, Suren Baghdasaryan wrote:
> > > On Mon, Jul 28, 2025 at 10:19 AM Vlastimil Babka <vbabka@suse.cz> wrote:
> > >> > +      */
> > >> > +     if (unlikely(vma->vm_mm != mm)) {
> > >> > +             /*
> > >> > +              * __mmdrop() is a heavy operation and we don't need RCU
> > >> > +              * protection here. Release RCU lock during these operations.
> > >> > +              */
> > >> > +             rcu_read_unlock();
> > >> > +             mmgrab(vma->vm_mm);
> > >> > +             vma_refcount_put(vma);
> > >>
> > >> The vma can go away here.
> > >
> > > No, the vma can't go away here because we are holding vm_refcnt. So,
> > > the vma and its mm are stable up until vma_refcount_put() drops
> > > vm_refcnt.
> >
> > But that's exactly what we're doing here?
>
> Ah, you are right. At the time of mmdrop() call the vma is already
> unstable. Let me fix it by copying the mm like we do in
> vma_refcount_put().

Fixed in v2: https://lore.kernel.org/all/20250728175355.2282375-1-surenb@google.com/
Thanks!

>
> >
> > >>
> > >> > +             mmdrop(vma->vm_mm);
> >
> > And here we reference the vma again?
> >
> > >> So we need to copy the vma->vm_mm first?
> > >>
> > >> > +             rcu_read_lock();
> > >> > +             return NULL;
> > >> > +     }
> > >> > +
> > >> >       /*
> > >> >        * Overflow of vm_lock_seq/mm_lock_seq might produce false locked result.
> > >> >        * False unlocked result is impossible because we modify and check