linux-kernel - Re: [PATCH 1/1] mm/madvise: initialize prev pointer in madvise_walk

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <e61a7aea-a87a-441f-809c-10acdfb82df4@lucifer.local>
Date: Tue, 17 Jun 2025 09:21:56 +0100
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: David Hildenbrand <david@...hat.com>
Cc: Lance Yang <ioworker0@...il.com>, akpm@...ux-foundation.org,
        21cnbao@...il.com, Liam.Howlett@...cle.com, vbabka@...e.cz,
        jannh@...gle.com, linux-kernel@...r.kernel.org, linux-mm@...ck.org,
        Lance Yang <lance.yang@...ux.dev>
Subject: Re: [PATCH 1/1] mm/madvise: initialize prev pointer in
 madvise_walk_vmas

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@...ux.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...

>
> 	vma = vma_modify_flags_name(&vmi, *prev, ...
>
> We should use Fixes: then.

So no we shouldn't...

>
>
> Acked-by: David Hildenbrand <david@...hat.com>

Sure? :)

>
> >
> > Initializing it to NULL makes the code safer and prevents potential bugs
> > if a future callback function attempts to read from it.
> >
> > Signed-off-by: Lance Yang <lance.yang@...ux.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;
> >   	/*
>
>
> --
> Cheers,
>
> David / dhildenb
>