Re: [PATCH 1/1] mm/madvise: initialize prev pointer in madvise_walk_vmas

[Lorenzo Stoakes <lorenzo.stoakes@oracle.com>]

On Tue, Jun 17, 2025 at 10:28:58AM +0200, David Hildenbrand wrote:
> On 17.06.25 10:21, Lorenzo Stoakes wrote:
> > On Tue, Jun 17, 2025 at 09:54:29AM +0200, David Hildenbrand wrote:
> > > On 17.06.25 04:05, Lance Yang 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.
> > >
> > > So, we are passing the pointer value to visit(), which is not undefined
> > > behavior.
> > >
> > > The issue would be if anybody takes a look at the value stored at that
> > > pointer. Because, already passing an uninitialized value to a (non-inlined)
> > > function is undefined behavior according to C.
> > >
> > > In madvise_update_vma()->vma_modify_flags_name() we do exactly that,
> > > correct?
> >
> > Err the parameter there is struct vm_area_struct **prev...
> >
> > We deref to the prev ptr which is unassigned yes but the pointer to the pointer isn't...
> >
>
> struct vm_area_struct *prev;
>
> is uninitialized.
>
> We pass &prev -> prevp, which now points at something uninitialized.
>
> Doing "*prevp =" is fine, because we will initialize.
>
> Doing "= *prep" is not fine, because the value was not initialized.

Yep sorry pre-coffee.

>
> > >
> > > 	vma = vma_modify_flags_name(&vmi, *prev, ...
> > >
> > > We should use Fixes: then.
> >
> > So no we shouldn't...
> >
> > >
> > >
> > > Acked-by: David Hildenbrand <david@redhat.com>
> >
> > Sure? :)
>
> Unless I am missing something important, yes :)

This solution isn't correct as prev == NULL when prev != NULL is wholly
incorrect.

We need a better solution.

>
> --
> Cheers,
>
> David / dhildenb
>