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: <f0a867eb-c66d-476d-8391-f8a4e9968c75@redhat.com>
Date: Tue, 17 Jun 2025 10:28:58 +0200
From: David Hildenbrand <david@...hat.com>
To: Lorenzo Stoakes <lorenzo.stoakes@...cle.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 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@...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...
> 

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.

>>
>> 	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? :)

Unless I am missing something important, yes :)

-- 
Cheers,

David / dhildenb