All of lore.kernel.org
 help / color / mirror / Atom feed
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: Thu, 04 Aug 2022 20:22:31 +0800	[thread overview]
Message-ID: <Yuu6B0vUuXvtEG8b@feng-clx> (raw)
In-Reply-To: <CACT4Y+Zzzj7+LwUwyMoBketXFBHRksnx148B1aLATZ48AU9o3w@mail.gmail.com>

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

On Thu, Aug 04, 2022 at 06:47:58PM +0800, Dmitry Vyukov wrote:
>  On Thu, 4 Aug 2022 at 08:29, Feng Tang <feng.tang@intel.com> wrote:
[...]
> >
> > ---8<---
> > From c4fc739ea4d5222f0aba4b42b59668d64a010082 Mon Sep 17 00:00:00 2001
> > From: Feng Tang <feng.tang@intel.com>
> > Date: Thu, 4 Aug 2022 13:25:35 +0800
> > Subject: [PATCH] mm: kasan: Add free_meta size info in struct kasan_cache
> >
> > When kasan is enabled for slab/slub, it may save kasan' free_meta
> > data in the former part of slab object data area in slab object
> > free path, which works fine.
> >
> > There is ongoing effort to extend slub's debug function which will
> > redzone the latter part of kmalloc object area, and when both of
> > the debug are enabled, there is possible conflict, especially when
> > the kmalloc object has small size, as caught by 0Day bot [1]
> >
> > For better information for slab/slub, add free_meta's data size
> > info 'kasan_cache', so that its users can take right action to
> > avoid data conflict.
> >
> > [1]. https://lore.kernel.org/lkml/YuYm3dWwpZwH58Hu(a)xsang-OptiPlex-9020/
> > Reported-by: kernel test robot <oliver.sang@intel.com>
> > Signed-off-by: Feng Tang <feng.tang@intel.com>
> 
> Acked-by: Dmitry Vyukov <dvyukov@google.com>
 
Thanks for your suggestion and review!

> I assume there will be a second patch that uses
> free_meta_size_in_object  in slub debug code.
 
Yes, it will be called in the slub kmalloc object redzone debug code.

Thanks,
Feng

> > ---
> >  include/linux/kasan.h | 2 ++
> >  mm/kasan/common.c     | 2 ++
> >  2 files changed, 4 insertions(+)
> >
> > diff --git a/include/linux/kasan.h b/include/linux/kasan.h
> > index b092277bf48d..293bdaa0ba09 100644
> > --- a/include/linux/kasan.h
> > +++ b/include/linux/kasan.h
> > @@ -100,6 +100,8 @@ static inline bool kasan_has_integrated_init(void)
> >  struct kasan_cache {
> >         int alloc_meta_offset;
> >         int free_meta_offset;
> > +       /* size of free_meta data saved in object's data area */
> > +       int free_meta_size_in_object;
> >         bool is_kmalloc;
> >  };
> >
> > diff --git a/mm/kasan/common.c b/mm/kasan/common.c
> > index 78be2beb7453..a627efa267d1 100644
> > --- a/mm/kasan/common.c
> > +++ b/mm/kasan/common.c
> > @@ -201,6 +201,8 @@ void __kasan_cache_create(struct kmem_cache *cache, unsigned int *size,
> >                         cache->kasan_info.free_meta_offset = KASAN_NO_FREE_META;
> >                         *size = ok_size;
> >                 }
> > +       } else {
> > +               cache->kasan_info.free_meta_size_in_object = sizeof(struct kasan_free_meta);
> >         }
> >
> >         /* Calculate size with optimal redzone. */
> > --
> > 2.27.0
> 

WARNING: multiple messages have this Message-ID (diff)
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: Thu, 4 Aug 2022 20:22:31 +0800	[thread overview]
Message-ID: <Yuu6B0vUuXvtEG8b@feng-clx> (raw)
In-Reply-To: <CACT4Y+Zzzj7+LwUwyMoBketXFBHRksnx148B1aLATZ48AU9o3w@mail.gmail.com>

On Thu, Aug 04, 2022 at 06:47:58PM +0800, Dmitry Vyukov wrote:
>  On Thu, 4 Aug 2022 at 08:29, Feng Tang <feng.tang@intel.com> wrote:
[...]
> >
> > ---8<---
> > From c4fc739ea4d5222f0aba4b42b59668d64a010082 Mon Sep 17 00:00:00 2001
> > From: Feng Tang <feng.tang@intel.com>
> > Date: Thu, 4 Aug 2022 13:25:35 +0800
> > Subject: [PATCH] mm: kasan: Add free_meta size info in struct kasan_cache
> >
> > When kasan is enabled for slab/slub, it may save kasan' free_meta
> > data in the former part of slab object data area in slab object
> > free path, which works fine.
> >
> > There is ongoing effort to extend slub's debug function which will
> > redzone the latter part of kmalloc object area, and when both of
> > the debug are enabled, there is possible conflict, especially when
> > the kmalloc object has small size, as caught by 0Day bot [1]
> >
> > For better information for slab/slub, add free_meta's data size
> > info 'kasan_cache', so that its users can take right action to
> > avoid data conflict.
> >
> > [1]. https://lore.kernel.org/lkml/YuYm3dWwpZwH58Hu@xsang-OptiPlex-9020/
> > Reported-by: kernel test robot <oliver.sang@intel.com>
> > Signed-off-by: Feng Tang <feng.tang@intel.com>
> 
> Acked-by: Dmitry Vyukov <dvyukov@google.com>
 
Thanks for your suggestion and review!

> I assume there will be a second patch that uses
> free_meta_size_in_object  in slub debug code.
 
Yes, it will be called in the slub kmalloc object redzone debug code.

Thanks,
Feng

> > ---
> >  include/linux/kasan.h | 2 ++
> >  mm/kasan/common.c     | 2 ++
> >  2 files changed, 4 insertions(+)
> >
> > diff --git a/include/linux/kasan.h b/include/linux/kasan.h
> > index b092277bf48d..293bdaa0ba09 100644
> > --- a/include/linux/kasan.h
> > +++ b/include/linux/kasan.h
> > @@ -100,6 +100,8 @@ static inline bool kasan_has_integrated_init(void)
> >  struct kasan_cache {
> >         int alloc_meta_offset;
> >         int free_meta_offset;
> > +       /* size of free_meta data saved in object's data area */
> > +       int free_meta_size_in_object;
> >         bool is_kmalloc;
> >  };
> >
> > diff --git a/mm/kasan/common.c b/mm/kasan/common.c
> > index 78be2beb7453..a627efa267d1 100644
> > --- a/mm/kasan/common.c
> > +++ b/mm/kasan/common.c
> > @@ -201,6 +201,8 @@ void __kasan_cache_create(struct kmem_cache *cache, unsigned int *size,
> >                         cache->kasan_info.free_meta_offset = KASAN_NO_FREE_META;
> >                         *size = ok_size;
> >                 }
> > +       } else {
> > +               cache->kasan_info.free_meta_size_in_object = sizeof(struct kasan_free_meta);
> >         }
> >
> >         /* Calculate size with optimal redzone. */
> > --
> > 2.27.0
> 


  reply	other threads:[~2022-08-04 12:22 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
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 [this message]
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=Yuu6B0vUuXvtEG8b@feng-clx \
    --to=feng.tang@intel.com \
    --cc=lkp@lists.01.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 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.