linux-kernel - Re: [PATCH] mm: correct type for vmalloc vm

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: <fca36160-d0f6-4ba9-afcf-609719b63c5a@lucifer.local>
Date: Tue, 29 Jul 2025 13:41:46 +0100
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: Pedro Falcato <pfalcato@...e.de>
Cc: Andrew Morton <akpm@...ux-foundation.org>, Mike Rapoport <rppt@...nel.org>,
        David Hildenbrand <david@...hat.com>,
        "Liam R . Howlett" <Liam.Howlett@...cle.com>,
        Vlastimil Babka <vbabka@...e.cz>,
        Suren Baghdasaryan <surenb@...gle.com>, Michal Hocko <mhocko@...e.com>,
        Jann Horn <jannh@...gle.com>, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org, Harry Yoo <harry.yoo@...cle.com>,
        Uladzislau Rezki <urezki@...il.com>
Subject: Re: [PATCH] mm: correct type for vmalloc vm_flags fields

Again to emphasise - the original series is not broken, this is just laying
the ground for a future change and fixing places where _that_ change would
be broken (and picked up then).

So there's nothing to be worried about here.

On Tue, Jul 29, 2025 at 01:28:31PM +0100, Pedro Falcato wrote:
> On Tue, Jul 29, 2025 at 12:49:06PM +0100, Lorenzo Stoakes wrote:
> > Several functions refer to the unfortunately named 'vm_flags' field when
> > referencing vmalloc flags, which happens to be the precise same name used
> > for VMA flags.
> >
> > As a result these were erroneously changed to use the vm_flags_t type
> > (which currently is a typedef equivalent to unsigned long).
> >
> > Currently this has no impact, but in future when vm_flags_t changes this
> > will result in issues, so change the type to unsigned long to account for
> > this.
> >
> > Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
> > Reported-by: Harry Yoo <harry.yoo@...cle.com>
> > Closes: https://lore.kernel.org/all/aIgSpAnU8EaIcqd9@hyeyoo/
>
> Reviewed-by: Pedro Falcato <pfalcato@...e.de>

Thanks.

>
> I think the existence of this mistake really tells us that we _really_ need some sort
> of type checking of this stuff, in the future.

I guess you forgot the off-list conversation in which I said I was going to
do exactly what you suggest here...

But yes, I already felt this way (as there seems no sensible way to make
static tools check carefully, and it's enormously easy to miss something),
and this is precisely what I intend to do.