[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ab080493-10cd-4f3b-8dd3-c67b4955a737@nfschina.com>
Date: Mon, 28 Jul 2025 17:08:57 +0800
From: liqiong <liqiong@...china.com>
To: Harry Yoo <harry.yoo@...cle.com>, Matthew Wilcox <willy@...radead.org>
Cc: Vlastimil Babka <vbabka@...e.cz>, Christoph Lameter <cl@...two.org>,
David Rientjes <rientjes@...gle.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Roman Gushchin <roman.gushchin@...ux.dev>, linux-mm@...ck.org,
linux-kernel@...r.kernel.org, stable@...r.kernel.org
Subject: Re: [PATCH v2] mm: slub: avoid deref of free pointer in sanity checks
if object is invalid
在 2025/7/28 13:24, Harry Yoo 写道:
> On Mon, Jul 28, 2025 at 04:29:22AM +0100, Matthew Wilcox wrote:
>> On Mon, Jul 28, 2025 at 10:06:42AM +0800, liqiong wrote:
>>>>> In this case it's an object pointer, not a freelist pointer.
>>>>> Or am I misunderstanding something?
>>>> Actually, in alloc_debug_processing() the pointer came from slab->freelist,
>>>> so I think saying either "invalid freelist pointer" or
>>>> "invalid object pointer" make sense...
>>> free_consistency_checks() has
>>> 'slab_err(s, slab, "Invalid object pointer 0x%p", object);'
>>> Maybe it is better, alloc_consisency_checks() has the same message.
>> No. Think about it.
> Haha, since I suggested that change, I feel like I have to rethink it
> and respond... Maybe I'm wrong again, but I love to be proven wrong :)
>
> On second thought,
>
> Unlike free_consistency_checks() where an arbitrary address can be
> passed, alloc_consistency_check() is not passed arbitrary addresses
> but only addresses from the freelist. So if a pointer is invalid
> there, it means the freelist pointer is invalid. And in all other
> parts of slub.c, such cases are described as "Free(list) pointer",
> or "Freechain" being invalid or corrupted.
>
> So to stay consistent "Invalid freelist pointer" would be the right choice :)
> Sorry for the confusion.
>
> Anyway, Li, to make progress on this I think it make sense to start by making
> object_err() resiliant against invalid pointers (as suggested by Matthew)?
> If you go down that path, this patch might no longer be required to fix
> the bug anyway...
>
> And the change would be quite small. Most part of print_trailer() is printing
> metadata and raw content of the object, which is risky when the pointer is
> invalid. In that case we'd only want to print the address of the invalid
> pointer and the information about slab (print_slab_info()) and nothing more.
>
Got it, I will a v3 patch, changing the message, and keep it simple, dropping the comments of object_err(),
just fix the issue.
Powered by blists - more mailing lists