All of lore.kernel.org
 help / color / mirror / Atom feed
From: Feng Tang <feng.tang@intel.com>
To: Dmitry Vyukov <dvyukov@google.com>
Cc: Vlastimil Babka <vbabka@suse.cz>,
	"Sang, Oliver" <oliver.sang@intel.com>, lkp <lkp@intel.com>,
	LKML <linux-kernel@vger.kernel.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"lkp@lists.01.org" <lkp@lists.01.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	"Christoph Lameter" <cl@linux.com>,
	Pekka Enberg <penberg@kernel.org>,
	David Rientjes <rientjes@google.com>,
	Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	Roman Gushchin <roman.gushchin@linux.dev>,
	Hyeonggon Yoo <42.hyeyoo@gmail.com>,
	"Hansen, Dave" <dave.hansen@intel.com>,
	Robin Murphy <robin.murphy@arm.com>,
	"John Garry" <john.garry@huawei.com>,
	Kefeng Wang <wangkefeng.wang@huawei.com>,
	Andrey Konovalov <andreyknvl@gmail.com>,
	Andrey Ryabinin <ryabinin.a.a@gmail.com>,
	Alexander Potapenko <glider@google.com>,
	"kasan-dev@googlegroups.com" <kasan-dev@googlegroups.com>
Subject: Re: [mm/slub] 3616799128: BUG_kmalloc-#(Not_tainted):kmalloc_Redzone_overwritten
Date: Tue, 2 Aug 2022 21:36:36 +0800	[thread overview]
Message-ID: <YukoZEm4Q6CSEKKj@feng-skl> (raw)
In-Reply-To: <CACT4Y+asjzrBu8ogRDt9hYYaAB3tZ2pK5HBkzkuMp106vQwKWQ@mail.gmail.com>

On Tue, Aug 02, 2022 at 06:30:44PM +0800, Dmitry Vyukov wrote:
> .On Tue, 2 Aug 2022 at 11:43, Vlastimil Babka <vbabka@suse.cz> wrote:
> >
> > On 8/2/22 09:06, Dmitry Vyukov wrote:
> > > On Tue, 2 Aug 2022 at 08:55, Feng Tang <feng.tang@intel.com> wrote:
> > >>
> > >> On Mon, Aug 01, 2022 at 10:23:23PM +0800, Vlastimil Babka wrote:
> > >> > On 8/1/22 08:21, Feng Tang wrote:
> > >> [snip]
> > >> > > Cc kansan  mail list.
> > >> > >
> > >> > > This is really related with KASAN debug, that in free path, some
> > >> > > kmalloc redzone ([orig_size+1, object_size]) area is written by
> > >> > > kasan to save free meta info.
> > >> > >
> > >> > > The callstack is:
> > >> > >
> > >> > >   kfree
> > >> > >     slab_free
> > >> > >       slab_free_freelist_hook
> > >> > >           slab_free_hook
> > >> > >             __kasan_slab_free
> > >> > >               ____kasan_slab_free
> > >> > >                 kasan_set_free_info
> > >> > >                   kasan_set_track
> > >> > >
> > >> > > And this issue only happens with "kmalloc-16" slab. Kasan has 2
> > >> > > tracks: alloc_track and free_track, for x86_64 test platform, most
> > >> > > of the slabs will reserve space for alloc_track, and reuse the
> > >> > > 'object' area for free_track.  The kasan free_track is 16 bytes
> > >> > > large, that it will occupy the whole 'kmalloc-16's object area,
> > >> > > so when kmalloc-redzone is enabled by this patch, the 'overwritten'
> > >> > > error is triggered.
> > >> > >
> > >> > > But it won't hurt other kmalloc slabs, as kasan's free meta won't
> > >> > > conflict with kmalloc-redzone which stay in the latter part of
> > >> > > kmalloc area.
> > >> > >
> > >> > > So the solution I can think of is:
> > >> > > * skip the kmalloc-redzone for kmalloc-16 only, or
> > >> > > * skip kmalloc-redzone if kasan is enabled, or
> > >> > > * let kasan reserve the free meta (16 bytes) outside of object
> > >> > >   just like for alloc meta
> > >> >
> > >> > Maybe we could add some hack that if both kasan and SLAB_STORE_USER is
> > >> > enabled, we bump the stored orig_size from <16 to 16? Similar to what
> > >> > __ksize() does.
> > >>
> > >> How about the following patch:
> > >>
> > >> ---
> > >> diff --git a/mm/slub.c b/mm/slub.c
> > >> index added2653bb0..33bbac2afaef 100644
> > >> --- a/mm/slub.c
> > >> +++ b/mm/slub.c
> > >> @@ -830,6 +830,16 @@ static inline void set_orig_size(struct kmem_cache *s,
> > >>         if (!slub_debug_orig_size(s))
> > >>                 return;
> > >>
> > >> +#ifdef CONFIG_KASAN
> > >> +       /*
> > >> +        * When kasan is enabled, it could save its free meta data in the
> > >> +        * start part of object area, so skip the kmalloc redzone check
> > >> +        * for small kmalloc slabs to avoid the data conflict.
> > >> +        */
> > >> +       if (s->object_size <= 32)
> > >> +               orig_size = s->object_size;
> > >> +#endif
> > >> +
> > >>         p += get_info_end(s);
> > >>         p += sizeof(struct track) * 2;
> > >>
> > >> I extend the size to 32 for potential's kasan meta data size increase.
> > >> This is tested locally, if people are OK with it, I can ask for 0Day's
> > >> help to verify this.
> >
> > Is there maybe some KASAN macro we can use instead of hardcoding 32?
> 
> kasan_free_meta is placed in the object data after freeing, so it can
> be sizeof(kasan_free_meta)

'kasan_free_meta' is defined in mm/kasan/kasan.h, to use it we need to
include "../kasan/kasan.h" in slub.c, or move its definition to
"include/linux/kasan.h"

Another idea is to save the info in kasan_info, like:

---
diff --git a/include/linux/kasan.h b/include/linux/kasan.h
index b092277bf48d..97e899948d0b 100644
--- a/include/linux/kasan.h
+++ b/include/linux/kasan.h
@@ -100,6 +100,7 @@ static inline bool kasan_has_integrated_init(void)
 struct kasan_cache {
 	int alloc_meta_offset;
 	int free_meta_offset;
+	int free_meta_size;
 	bool is_kmalloc;
 };
 
diff --git a/mm/kasan/common.c b/mm/kasan/common.c
index c40c0e7b3b5f..7bd82c5ec264 100644
--- a/mm/kasan/common.c
+++ b/mm/kasan/common.c
@@ -178,6 +178,8 @@ void __kasan_cache_create(struct kmem_cache *cache, unsigned int *size,
 		return;
 	}
 
+	cache->kasan_info.free_meta_size = sizeof(struct free_meta_offset);
+
 	/*
 	 * Add free meta into redzone when it's not possible to store
 	 * it in the object. This is the case when:

Thanks,
Feng

WARNING: multiple messages have this Message-ID (diff)
From: Feng Tang <feng.tang@intel.com>
To: lkp@lists.01.org
Subject: Re: [mm/slub] 3616799128: BUG_kmalloc-#(Not_tainted):kmalloc_Redzone_overwritten
Date: Tue, 02 Aug 2022 21:36:36 +0800	[thread overview]
Message-ID: <YukoZEm4Q6CSEKKj@feng-skl> (raw)
In-Reply-To: <CACT4Y+asjzrBu8ogRDt9hYYaAB3tZ2pK5HBkzkuMp106vQwKWQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 4501 bytes --]

On Tue, Aug 02, 2022 at 06:30:44PM +0800, Dmitry Vyukov wrote:
> .On Tue, 2 Aug 2022 at 11:43, Vlastimil Babka <vbabka@suse.cz> wrote:
> >
> > On 8/2/22 09:06, Dmitry Vyukov wrote:
> > > On Tue, 2 Aug 2022 at 08:55, Feng Tang <feng.tang@intel.com> wrote:
> > >>
> > >> On Mon, Aug 01, 2022 at 10:23:23PM +0800, Vlastimil Babka wrote:
> > >> > On 8/1/22 08:21, Feng Tang wrote:
> > >> [snip]
> > >> > > Cc kansan  mail list.
> > >> > >
> > >> > > This is really related with KASAN debug, that in free path, some
> > >> > > kmalloc redzone ([orig_size+1, object_size]) area is written by
> > >> > > kasan to save free meta info.
> > >> > >
> > >> > > The callstack is:
> > >> > >
> > >> > >   kfree
> > >> > >     slab_free
> > >> > >       slab_free_freelist_hook
> > >> > >           slab_free_hook
> > >> > >             __kasan_slab_free
> > >> > >               ____kasan_slab_free
> > >> > >                 kasan_set_free_info
> > >> > >                   kasan_set_track
> > >> > >
> > >> > > And this issue only happens with "kmalloc-16" slab. Kasan has 2
> > >> > > tracks: alloc_track and free_track, for x86_64 test platform, most
> > >> > > of the slabs will reserve space for alloc_track, and reuse the
> > >> > > 'object' area for free_track.  The kasan free_track is 16 bytes
> > >> > > large, that it will occupy the whole 'kmalloc-16's object area,
> > >> > > so when kmalloc-redzone is enabled by this patch, the 'overwritten'
> > >> > > error is triggered.
> > >> > >
> > >> > > But it won't hurt other kmalloc slabs, as kasan's free meta won't
> > >> > > conflict with kmalloc-redzone which stay in the latter part of
> > >> > > kmalloc area.
> > >> > >
> > >> > > So the solution I can think of is:
> > >> > > * skip the kmalloc-redzone for kmalloc-16 only, or
> > >> > > * skip kmalloc-redzone if kasan is enabled, or
> > >> > > * let kasan reserve the free meta (16 bytes) outside of object
> > >> > >   just like for alloc meta
> > >> >
> > >> > Maybe we could add some hack that if both kasan and SLAB_STORE_USER is
> > >> > enabled, we bump the stored orig_size from <16 to 16? Similar to what
> > >> > __ksize() does.
> > >>
> > >> How about the following patch:
> > >>
> > >> ---
> > >> diff --git a/mm/slub.c b/mm/slub.c
> > >> index added2653bb0..33bbac2afaef 100644
> > >> --- a/mm/slub.c
> > >> +++ b/mm/slub.c
> > >> @@ -830,6 +830,16 @@ static inline void set_orig_size(struct kmem_cache *s,
> > >>         if (!slub_debug_orig_size(s))
> > >>                 return;
> > >>
> > >> +#ifdef CONFIG_KASAN
> > >> +       /*
> > >> +        * When kasan is enabled, it could save its free meta data in the
> > >> +        * start part of object area, so skip the kmalloc redzone check
> > >> +        * for small kmalloc slabs to avoid the data conflict.
> > >> +        */
> > >> +       if (s->object_size <= 32)
> > >> +               orig_size = s->object_size;
> > >> +#endif
> > >> +
> > >>         p += get_info_end(s);
> > >>         p += sizeof(struct track) * 2;
> > >>
> > >> I extend the size to 32 for potential's kasan meta data size increase.
> > >> This is tested locally, if people are OK with it, I can ask for 0Day's
> > >> help to verify this.
> >
> > Is there maybe some KASAN macro we can use instead of hardcoding 32?
> 
> kasan_free_meta is placed in the object data after freeing, so it can
> be sizeof(kasan_free_meta)

'kasan_free_meta' is defined in mm/kasan/kasan.h, to use it we need to
include "../kasan/kasan.h" in slub.c, or move its definition to
"include/linux/kasan.h"

Another idea is to save the info in kasan_info, like:

---
diff --git a/include/linux/kasan.h b/include/linux/kasan.h
index b092277bf48d..97e899948d0b 100644
--- a/include/linux/kasan.h
+++ b/include/linux/kasan.h
@@ -100,6 +100,7 @@ static inline bool kasan_has_integrated_init(void)
 struct kasan_cache {
 	int alloc_meta_offset;
 	int free_meta_offset;
+	int free_meta_size;
 	bool is_kmalloc;
 };
 
diff --git a/mm/kasan/common.c b/mm/kasan/common.c
index c40c0e7b3b5f..7bd82c5ec264 100644
--- a/mm/kasan/common.c
+++ b/mm/kasan/common.c
@@ -178,6 +178,8 @@ void __kasan_cache_create(struct kmem_cache *cache, unsigned int *size,
 		return;
 	}
 
+	cache->kasan_info.free_meta_size = sizeof(struct free_meta_offset);
+
 	/*
 	 * Add free meta into redzone when it's not possible to store
 	 * it in the object. This is the case when:

Thanks,
Feng

  reply	other threads:[~2022-08-02 13:37 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-27  7:10 [PATCH v3 0/3] mm/slub: some debug enhancements Feng Tang
2022-07-27  7:10 ` [PATCH v3 1/3] mm/slub: enable debugging memory wasting of kmalloc Feng Tang
2022-07-27 10:20   ` Christoph Lameter
2022-07-27 12:59     ` Feng Tang
2022-07-27 14:12     ` Vlastimil Babka
2022-07-27  7:10 ` [PATCH v3 2/3] mm/slub: only zero the requested size of buffer for kzalloc Feng Tang
2022-07-27  7:10 ` [PATCH v3 3/3] mm/slub: extend redzone check to cover extra allocated kmalloc space than requested Feng Tang
2022-07-31  6:53   ` [mm/slub] 3616799128: BUG_kmalloc-#(Not_tainted):kmalloc_Redzone_overwritten kernel test robot
2022-07-31  6:53     ` kernel test robot
2022-07-31  8:16     ` Feng Tang
2022-07-31  8:16       ` Feng Tang
2022-08-01  6:21       ` Feng Tang
2022-08-01  6:21         ` Feng Tang
2022-08-01  7:26         ` Dmitry Vyukov
2022-08-01  7:26           ` Dmitry Vyukov
2022-08-01  7:48           ` Feng Tang
2022-08-01  7:48             ` Feng Tang
2022-08-01  8:13             ` Christoph Lameter
2022-08-01  8:13               ` Christoph Lameter
2022-08-01 14:23         ` Vlastimil Babka
2022-08-01 14:23           ` Vlastimil Babka
2022-08-02  6:54           ` Feng Tang
2022-08-02  6:54             ` Feng Tang
2022-08-02  7:06             ` Dmitry Vyukov
2022-08-02  7:06               ` Dmitry Vyukov
2022-08-02  7:46               ` Feng Tang
2022-08-02  7:46                 ` Feng Tang
2022-08-02  7:59                 ` Dmitry Vyukov
2022-08-02  7:59                   ` Dmitry Vyukov
2022-08-02  8:44                   ` Feng Tang
2022-08-02  8:44                     ` Feng Tang
2022-08-02  9:43               ` Vlastimil Babka
2022-08-02  9:43                 ` Vlastimil Babka
2022-08-02 10:30                 ` Dmitry Vyukov
2022-08-02 10:30                   ` Dmitry Vyukov
2022-08-02 13:36                   ` Feng Tang [this message]
2022-08-02 13:36                     ` Feng Tang
2022-08-02 14:38                     ` Dmitry Vyukov
2022-08-02 14:38                       ` Dmitry Vyukov
2022-08-04  6:28                       ` Feng Tang
2022-08-04  6:28                         ` Feng Tang
2022-08-04 10:47                         ` Dmitry Vyukov
2022-08-04 10:47                           ` Dmitry Vyukov
2022-08-04 12:22                           ` Feng Tang
2022-08-04 12:22                             ` Feng Tang
2022-08-15  7:27                             ` Feng Tang
2022-08-15  7:27                               ` Feng Tang
2022-08-16 13:27                               ` Oliver Sang
2022-08-16 13:27                                 ` Oliver Sang
2022-08-16 14:12                                 ` Feng Tang
2022-08-16 14:12                                   ` Feng Tang
2022-08-02 10:31                 ` Dmitry Vyukov
2022-08-02 10:31                   ` Dmitry Vyukov
2022-08-02  6:59           ` Dmitry Vyukov
2022-08-02  6:59             ` Dmitry Vyukov

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=YukoZEm4Q6CSEKKj@feng-skl \
    --to=feng.tang@intel.com \
    --cc=42.hyeyoo@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=andreyknvl@gmail.com \
    --cc=cl@linux.com \
    --cc=dave.hansen@intel.com \
    --cc=dvyukov@google.com \
    --cc=glider@google.com \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=john.garry@huawei.com \
    --cc=kasan-dev@googlegroups.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lkp@intel.com \
    --cc=lkp@lists.01.org \
    --cc=oliver.sang@intel.com \
    --cc=penberg@kernel.org \
    --cc=rientjes@google.com \
    --cc=robin.murphy@arm.com \
    --cc=roman.gushchin@linux.dev \
    --cc=ryabinin.a.a@gmail.com \
    --cc=vbabka@suse.cz \
    --cc=wangkefeng.wang@huawei.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.