From: Harry Yoo <harry.yoo@oracle.com>
To: Matthew Wilcox <willy@infradead.org>
Cc: Vlastimil Babka <vbabka@suse.cz>, Li Qiong <liqiong@nfschina.com>,
Christoph Lameter <cl@gentwo.org>,
David Rientjes <rientjes@google.com>,
Andrew Morton <akpm@linux-foundation.org>,
Roman Gushchin <roman.gushchin@linux.dev>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
stable@vger.kernel.org
Subject: Re: [PATCH v2] mm: slub: avoid deref of free pointer in sanity checks if object is invalid
Date: Sat, 26 Jul 2025 04:55:06 +0900 [thread overview]
Message-ID: <aIPhGvYgF0oC8kDa@hyeyoo> (raw)
In-Reply-To: <aIO6m2C8K4SrJ6mp@casper.infradead.org>
On Fri, Jul 25, 2025 at 06:10:51PM +0100, Matthew Wilcox wrote:
> On Fri, Jul 25, 2025 at 06:47:01PM +0200, Vlastimil Babka wrote:
> > On 7/25/25 08:49, Li Qiong wrote:
> > > For debugging, object_err() prints free pointer of the object.
> > > However, if check_valid_pointer() returns false for a object,
> > > dereferncing `object + s->offset` can lead to a crash. Therefore,
> > > print the object's address in such cases.
>
> I don't know where this patch came from (was it cc'd to linux-mm? i
> don't see it)
https://lore.kernel.org/all/20250725024854.1201926-1-liqiong@nfschina.com
Looks like it's rejected by linux-mm for some reason..
> > > +/*
> > > + * object - should be a valid object.
> > > + * check_valid_pointer(s, slab, object) should be true.
> > > + */
>
> This comment is very confusing. It tries to ape kernel-doc style,
> but if it were kernel-doc, the word before the hyphen should be the name
> of the function, and it isn't. If we did use kernel-doc for this, we'd
> use @object to denote that we're documenting the argument.
Yes, the comment is indeed confusing and agree with your point.
When I suggested it I expected adding something like:
/* print_trailer() may deref invalid freepointer if object pointer is invalid */
WARN_ON_ONCE(!check_valid_pointer(s, slab, object));
to be added to object_err().
> But I don't see the need to pretend this is related to kernel-doc. This
> would be better:
>
> /*
> * 'object' must be a valid pointer into this slab. ie
> * check_valid_pointer() would return true
> */
>
> I'm sure better wording for that is possible ...
>
> > > if (!check_valid_pointer(s, slab, object)) {
> > > - object_err(s, slab, object, "Freelist Pointer check fails");
> > > + slab_err(s, slab, "Invalid object pointer 0x%p", object);
> > > return 0;
>
> No, the error message is now wrong. It's not an object, it's the
> freelist pointer.
Because it's the object is about to be allocated, it will look like
this:
object pointer -> obj: [ garbage ][ freelist pointer ][ garbage ]
SLUB uses check_valid_pointer() to check either 1) freelist pointer of
an object is valid (e.g. in check_object()), or 2) an object pointer
points to a valid address (e.g. in free_debug_processing()).
In this case it's an object pointer, not a freelist pointer.
Or am I misunderstanding something?
> slab_err(s, slab, "Invalid freelist pointer %p", object);
>
> (the 0x%p is wrong because it will print 0x twice)
"0x%p" is used all over the place in mm/slub.c.
In the printk documentation [1]:
> Plain Pointers
> %p abcdef12 or 00000000abcdef12
0x%p should be 0xabcdef12 or 0x00000000abcdef12, no?
[1] https://www.kernel.org/doc/html/next/core-api/printk-formats.html#printk-specifiers
> But I think there are even more things wrong here. Like slab_err() is
> not nerely as severe as slab_bug(), which is what used to be called.
What do you mean by slab_err() is not as severe as slab_bug()?
Both object_err() and slab_err() add a taint and trigger a WARNING.
> And object_err() adds a taint, which this skips.
adding a taint is done via
slab_err()->__slab_err()->add_taint()
--
Cheers,
Harry / Hyeonggon
next prev parent reply other threads:[~2025-07-25 19:55 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20250725064919.1785537-1-liqiong@nfschina.com>
2025-07-25 16:47 ` Vlastimil Babka
2025-07-25 17:10 ` Matthew Wilcox
2025-07-25 19:22 ` Matthew Wilcox
2025-07-25 22:49 ` Harry Yoo
2025-07-25 19:55 ` Harry Yoo [this message]
2025-07-25 23:00 ` Harry Yoo
[not found] ` <e6f14d8a-5d32-473e-ba2d-1064ab8ef8fe@nfschina.com>
2025-07-28 3:29 ` Matthew Wilcox
2025-07-28 5:24 ` Harry Yoo
[not found] ` <ab080493-10cd-4f3b-8dd3-c67b4955a737@nfschina.com>
2025-07-28 13:38 ` Harry Yoo
2025-07-28 8:52 ` Vlastimil Babka
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aIPhGvYgF0oC8kDa@hyeyoo \
--to=harry.yoo@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=cl@gentwo.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=liqiong@nfschina.com \
--cc=rientjes@google.com \
--cc=roman.gushchin@linux.dev \
--cc=stable@vger.kernel.org \
--cc=vbabka@suse.cz \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox