linux-kernel - Re: [RFC PATCH V3 5/7] mm/memcontrol,alloc_tag: handle slabobj

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: <aQHLDTwwEuswvNWv@hyeyoo>
Date: Wed, 29 Oct 2025 17:06:37 +0900
From: Harry Yoo <harry.yoo@...cle.com>
To: Suren Baghdasaryan <surenb@...gle.com>
Cc: akpm@...ux-foundation.org, vbabka@...e.cz, andreyknvl@...il.com,
        cl@...ux.com, dvyukov@...gle.com, glider@...gle.com,
        hannes@...xchg.org, linux-mm@...ck.org, mhocko@...nel.org,
        muchun.song@...ux.dev, rientjes@...gle.com, roman.gushchin@...ux.dev,
        ryabinin.a.a@...il.com, shakeel.butt@...ux.dev,
        vincenzo.frascino@....com, yeoreum.yun@....com, tytso@....edu,
        adilger.kernel@...ger.ca, linux-ext4@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH V3 5/7] mm/memcontrol,alloc_tag: handle slabobj_ext
 access under KASAN poison

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@...cle.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@...il.com>
> > Signed-off-by: Harry Yoo <harry.yoo@...cle.com>
> > ---

-- 
Cheers,
Harry / Hyeonggon