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: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().

>
> >>
> >> > +             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