All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vlastimil Babka <vbabka@suse.cz>
To: Suren Baghdasaryan <surenb@google.com>
Cc: akpm@linux-foundation.org, jannh@google.com,
	Liam.Howlett@oracle.com, lorenzo.stoakes@oracle.com,
	pfalcato@suse.de, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH 1/1] mm: fix a UAF when vma->mm is freed after vma->vm_refcnt got dropped
Date: Mon, 28 Jul 2025 19:39:08 +0200	[thread overview]
Message-ID: <97938dc6-5dfe-4591-ba53-3729934c1235@suse.cz> (raw)
In-Reply-To: <CAJuCfpGZXGF_k_QVQqHWZpnypB-sWB8hwZeOYMOD0xmAFOBxkA@mail.gmail.com>

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?

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


  reply	other threads:[~2025-07-28 17:39 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-28 17:09 [PATCH 1/1] mm: fix a UAF when vma->mm is freed after vma->vm_refcnt got dropped Suren Baghdasaryan
2025-07-28 17:16 ` Suren Baghdasaryan
2025-07-28 17:19 ` Vlastimil Babka
2025-07-28 17:37   ` Suren Baghdasaryan
2025-07-28 17:39     ` Vlastimil Babka [this message]
2025-07-28 17:43       ` Suren Baghdasaryan
2025-07-28 17:55         ` Suren Baghdasaryan

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=97938dc6-5dfe-4591-ba53-3729934c1235@suse.cz \
    --to=vbabka@suse.cz \
    --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=lorenzo.stoakes@oracle.com \
    --cc=pfalcato@suse.de \
    --cc=stable@vger.kernel.org \
    --cc=surenb@google.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.