All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lance Yang <lance.yang@linux.dev>
To: Barry Song <21cnbao@gmail.com>
Cc: akpm@linux-foundation.org, david@redhat.com,
	Liam.Howlett@oracle.com, vbabka@suse.cz, jannh@google.com,
	lorenzo.stoakes@oracle.com, linux-kernel@vger.kernel.org,
	linux-mm@kvack.org, Lance Yang <ioworker0@gmail.com>
Subject: Re: [PATCH 1/1] mm/madvise: initialize prev pointer in madvise_walk_vmas
Date: Tue, 17 Jun 2025 12:57:29 +0800	[thread overview]
Message-ID: <6fe09fdd-ff38-42cc-b101-520204213f82@linux.dev> (raw)
In-Reply-To: <CAGsJ_4ySwMuKGYxywY+RH_FkNvjsThhvFQr+d1++KykOqjxarg@mail.gmail.com>



On 2025/6/17 10:24, Barry Song wrote:
> On Tue, Jun 17, 2025 at 2:05 PM Lance Yang <ioworker0@gmail.com> wrote:
>>
>> From: Lance Yang <lance.yang@linux.dev>
>>
>> The prev pointer was uninitialized, which could lead to undefined behavior
>> where its address is taken and passed to the visit() callback without being
>> assigned a value.
>>
>> Initializing it to NULL makes the code safer and prevents potential bugs
>> if a future callback function attempts to read from it.
> 
> Is there any read-before-write case here? I haven't found one.


It appears that the following is a call chain showing the read-before-write
of prev:

-> madvise_vma_anon_name(..., struct vm_area_struct **prev, ...)
         Receives the address of madvise_walk_vmas's prev.
         Passes this pointer directly to madvise_update_vma.
         Note that prev is not updated before visit() is called
         if !(start > vma->vm_start) in the slow path.

         -> madvise_update_vma(..., struct vm_area_struct **prev, ...)
                 It calls the next function with *prev.

                 -> vma_modify_flags_name(..., *prev, ...)
                         Stores the value of madvise_walk_vmas's prev in 
vmg.prev
                         using the VMG_VMA_STATE macro.

                         -> vma_modify(struct vma_merge_struct *vmg)
                                 Receives the vmg struct.
                                 Passes vmg to vma_merge_existing_range.

                                 -> vma_merge_existing_range(struct 
vma_merge_struct *vmg)
                                         Retrieves the value: struct 
vm_area_struct *prev = vmg->prev;
                                         The value is now used in a 
conditional check:
                                         VM_WARN_ON_VMG(prev && start <= 
prev->vm_start, vmg)
                                         If prev was uninitialized, this 
would cause a crash.

Thanks,
Lance

> 
> It also looks like we're assuming that *prev == NULL implies
> a specific condition:
> 
> *prev = NULL;   /* tell sys_madvise we drop mmap_lock */
> 
> *prev = NULL; /* mmap_lock has been dropped, prev is stale */
> 
>>
>> Signed-off-by: Lance Yang <lance.yang@linux.dev>
>> ---
>>   mm/madvise.c | 4 ++--
>>   1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/mm/madvise.c b/mm/madvise.c
>> index 267d8e4adf31..c87325000303 100644
>> --- a/mm/madvise.c
>> +++ b/mm/madvise.c
>> @@ -1536,10 +1536,10 @@ int madvise_walk_vmas(struct mm_struct *mm, unsigned long start,
>>                                     struct vm_area_struct **prev, unsigned long start,
>>                                     unsigned long end, void *arg))
>>   {
>> +       struct vm_area_struct *prev = NULL;
>>          struct vm_area_struct *vma;
>> -       struct vm_area_struct *prev;
>> -       unsigned long tmp;
>>          int unmapped_error = 0;
>> +       unsigned long tmp;
>>          int error;
>>
>>          /*
>> --
>> 2.49.0
>>
> 
> Thanks
> Barry



  reply	other threads:[~2025-06-17  4:57 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-17  2:05 [PATCH 1/1] mm/madvise: initialize prev pointer in madvise_walk_vmas Lance Yang
2025-06-17  2:24 ` Barry Song
2025-06-17  4:57   ` Lance Yang [this message]
2025-06-17  5:19     ` Barry Song
2025-06-17  6:03       ` Lance Yang
2025-06-17  7:54 ` David Hildenbrand
2025-06-17  8:18   ` Lance Yang
2025-06-17  8:21   ` Lorenzo Stoakes
2025-06-17  8:28     ` David Hildenbrand
2025-06-17  8:34       ` Lorenzo Stoakes
2025-06-17  8:38         ` David Hildenbrand
2025-06-17  8:50           ` Lorenzo Stoakes
2025-06-17  8:53             ` David Hildenbrand
2025-06-17  8:43   ` Lorenzo Stoakes
2025-06-17  8:51     ` Lorenzo Stoakes
2025-06-17  8:26 ` Lorenzo Stoakes
2025-06-17  8:50 ` Lorenzo Stoakes
2025-06-17  9:21   ` Lance Yang
2025-06-17  9:26     ` Lorenzo Stoakes

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=6fe09fdd-ff38-42cc-b101-520204213f82@linux.dev \
    --to=lance.yang@linux.dev \
    --cc=21cnbao@gmail.com \
    --cc=Liam.Howlett@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=david@redhat.com \
    --cc=ioworker0@gmail.com \
    --cc=jannh@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lorenzo.stoakes@oracle.com \
    --cc=vbabka@suse.cz \
    /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.