Re: [RFC PATCH V3 5/7] mm/memcontrol,alloc_tag: handle slabobj_ext access under KASAN poison

[Harry Yoo <harry.yoo@oracle.com>]

On Tue, Oct 28, 2025 at 04:03:22PM -0700, Suren Baghdasaryan wrote:
> On Mon, Oct 27, 2025 at 5:29 AM Harry Yoo <harry.yoo@oracle.com> wrote:
> >
> > In the near future, slabobj_ext may reside outside the allocated slab
> > object range within a slab, which could be reported as an out-of-bounds
> > access by KASAN. To prevent false positives, explicitly disable KASAN
> > and KMSAN checks when accessing slabobj_ext.
> 
> Hmm. This is fragile IMO. Every time someone accesses slabobj_ext they
> should remember to call
> metadata_access_enable/metadata_access_disable.

Good point!

> Have you considered replacing slab_obj_ext() function with
> get_slab_obj_ext()/put_slab_obj_ext()? get_slab_obj_ext() can call
> metadata_access_enable() and return slabobj_ext as it does today.
> put_slab_obj_ext() will simple call metadata_access_disable(). WDYT?

I did think about it, and I thought introducing get and put helpers
may be misunderstood as doing some kind of reference counting...

but yeah probably I'm being too paranoid and
I'll try this and document that

1) the user needs to use get and put pair to access slabobj_ext
   metadata, and

2) calling get and put pair multiple times has no effect.

> > While an alternative approach could be to unpoison slabobj_ext,
> > out-of-bounds accesses outside the slab allocator are generally more
> > common.
> >
> > Move metadata_access_enable()/disable() helpers to mm/slab.h so that
> > it can be used outside mm/slub.c. Wrap accesses to slabobj_ext metadata
> > in memcg and alloc_tag code with these helpers.
> >
> > Call kasan_reset_tag() in slab_obj_ext() before returning the address to
> > prevent SW or HW tag-based KASAN from reporting false positives.
> >
> > Suggested-by: Andrey Konovalov <andreyknvl@gmail.com>
> > Signed-off-by: Harry Yoo <harry.yoo@oracle.com>
> > ---

-- 
Cheers,
Harry / Hyeonggon