All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Kuan-Ying Lee (李冠穎)" <Kuan-Ying.Lee@mediatek.com>
To: "andreyknvl@gmail.com" <andreyknvl@gmail.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-mediatek@lists.infradead.org"
	<linux-mediatek@lists.infradead.org>,
	"Qun-wei Lin (林群崴)" <Qun-wei.Lin@mediatek.com>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"Chinwen Chang (張錦文)" <chinwen.chang@mediatek.com>,
	"dvyukov@google.com" <dvyukov@google.com>,
	"kasan-dev@googlegroups.com" <kasan-dev@googlegroups.com>,
	"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
	"ryabinin.a.a@gmail.com" <ryabinin.a.a@gmail.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"vincenzo.frascino@arm.com" <vincenzo.frascino@arm.com>,
	"glider@google.com" <glider@google.com>,
	"matthias.bgg@gmail.com" <matthias.bgg@gmail.com>
Subject: Re: [PATCH v2] kasan: infer the requested size by scanning shadow memory
Date: Sat, 28 Jan 2023 14:58:30 +0000	[thread overview]
Message-ID: <414630a65853f18c450cf1451e013b749382cbac.camel@mediatek.com> (raw)
In-Reply-To: <CA+fCnZcS-p5nCALg4-96cp+sXNZSvN_u=L+=xK+zaH2rigJMKw@mail.gmail.com>

On Mon, 2023-01-23 at 22:46 +0100, Andrey Konovalov wrote:
> On Wed, Jan 18, 2023 at 10:39 AM Kuan-Ying Lee
> <Kuan-Ying.Lee@mediatek.com> wrote:
> > 
> > We scan the shadow memory to infer the requested size instead of
> > printing cache->object_size directly.
> > 
> > This patch will fix the confusing kasan slab-out-of-bounds
> > report like below. [1]
> > Report shows "cache kmalloc-192 of size 192", but user
> > actually kmalloc(184).
> > 
> > ==================================================================
> > BUG: KASAN: slab-out-of-bounds in _find_next_bit+0x143/0x160
> > lib/find_bit.c:109
> > Read of size 8 at addr ffff8880175766b8 by task kworker/1:1/26
> > ...
> > The buggy address belongs to the object at ffff888017576600
> >  which belongs to the cache kmalloc-192 of size 192
> > The buggy address is located 184 bytes inside of
> >  192-byte region [ffff888017576600, ffff8880175766c0)
> > ...
> > Memory state around the buggy address:
> >  ffff888017576580: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
> >  ffff888017576600: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > > ffff888017576680: 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc
> > 
> >                                         ^
> >  ffff888017576700: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> >  ffff888017576780: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> > ==================================================================
> > 
> > After this patch, slab-out-of-bounds report will show as below.
> > ==================================================================
> > ...
> > The buggy address belongs to the object at ffff888017576600
> >  which belongs to the cache kmalloc-192 of size 192
> > The buggy address is located 0 bytes right of
> >  allocated 184-byte region [ffff888017576600, ffff8880175766b8)
> > ...
> > ==================================================================
> > 
> > Link: 
> > https://urldefense.com/v3/__https://bugzilla.kernel.org/show_bug.cgi?id=216457__;!!CTRNKA9wMg0ARbw!iEOOICl7DzhvfYobmQ8MsNFAWmbqicXdjd0LYWw9uBOqwj8lai7oEODVdRJyWUEXr11A3-m7wbIX2cdpxLwiW6Tm$
> > $   [1]
> > 
> > Signed-off-by: Kuan-Ying Lee <Kuan-Ying.Lee@mediatek.com>
> > ---
> > V1 -> V2:
> >  - Implement getting allocated size of object for tag-based kasan.
> >  - Refine the kasan report.
> >  - Check if it is slab-out-of-bounds report type.
> >  - Thanks for Andrey and Dmitry suggestion.
> 
> Hi Kuan-Ying,
> 
> I came up with a few more things to fix while testing your patch and
> decided to address them myself. Please check the v3 here:
> 
> 
https://urldefense.com/v3/__https://github.com/xairy/linux/commit/012a584a9f11ba08a6051b075f7fd0a0eb54c719__;!!CTRNKA9wMg0ARbw!iEOOICl7DzhvfYobmQ8MsNFAWmbqicXdjd0LYWw9uBOqwj8lai7oEODVdRJyWUEXr11A3-m7wbIX2cdpxNwCtfpJ$ 
>  
> 
> The significant changes are to print "freed" for a slab-use-after-
> free
> and only print the region state for the Generic mode (printing it for
> Tag-Based modes doesn't work properly atm, see the comment in the
> code). The rest is clean-ups and a few added comments. See the full
> list of changes in the commit message.
> 
> Please check whether this v3 looks good to you, and then feel free to
> submit it.

It looks good to me.
I will send the v3.
Thank you.

> Thank you!

WARNING: multiple messages have this Message-ID (diff)
From: "Kuan-Ying Lee (李冠穎)" <Kuan-Ying.Lee@mediatek.com>
To: "andreyknvl@gmail.com" <andreyknvl@gmail.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-mediatek@lists.infradead.org"
	<linux-mediatek@lists.infradead.org>,
	"Qun-wei Lin (林群崴)" <Qun-wei.Lin@mediatek.com>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"Chinwen Chang (張錦文)" <chinwen.chang@mediatek.com>,
	"dvyukov@google.com" <dvyukov@google.com>,
	"kasan-dev@googlegroups.com" <kasan-dev@googlegroups.com>,
	"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
	"ryabinin.a.a@gmail.com" <ryabinin.a.a@gmail.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"vincenzo.frascino@arm.com" <vincenzo.frascino@arm.com>,
	"glider@google.com" <glider@google.com>,
	"matthias.bgg@gmail.com" <matthias.bgg@gmail.com>
Subject: Re: [PATCH v2] kasan: infer the requested size by scanning shadow memory
Date: Sat, 28 Jan 2023 14:58:30 +0000	[thread overview]
Message-ID: <414630a65853f18c450cf1451e013b749382cbac.camel@mediatek.com> (raw)
In-Reply-To: <CA+fCnZcS-p5nCALg4-96cp+sXNZSvN_u=L+=xK+zaH2rigJMKw@mail.gmail.com>

On Mon, 2023-01-23 at 22:46 +0100, Andrey Konovalov wrote:
> On Wed, Jan 18, 2023 at 10:39 AM Kuan-Ying Lee
> <Kuan-Ying.Lee@mediatek.com> wrote:
> > 
> > We scan the shadow memory to infer the requested size instead of
> > printing cache->object_size directly.
> > 
> > This patch will fix the confusing kasan slab-out-of-bounds
> > report like below. [1]
> > Report shows "cache kmalloc-192 of size 192", but user
> > actually kmalloc(184).
> > 
> > ==================================================================
> > BUG: KASAN: slab-out-of-bounds in _find_next_bit+0x143/0x160
> > lib/find_bit.c:109
> > Read of size 8 at addr ffff8880175766b8 by task kworker/1:1/26
> > ...
> > The buggy address belongs to the object at ffff888017576600
> >  which belongs to the cache kmalloc-192 of size 192
> > The buggy address is located 184 bytes inside of
> >  192-byte region [ffff888017576600, ffff8880175766c0)
> > ...
> > Memory state around the buggy address:
> >  ffff888017576580: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
> >  ffff888017576600: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > > ffff888017576680: 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc
> > 
> >                                         ^
> >  ffff888017576700: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> >  ffff888017576780: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> > ==================================================================
> > 
> > After this patch, slab-out-of-bounds report will show as below.
> > ==================================================================
> > ...
> > The buggy address belongs to the object at ffff888017576600
> >  which belongs to the cache kmalloc-192 of size 192
> > The buggy address is located 0 bytes right of
> >  allocated 184-byte region [ffff888017576600, ffff8880175766b8)
> > ...
> > ==================================================================
> > 
> > Link: 
> > https://urldefense.com/v3/__https://bugzilla.kernel.org/show_bug.cgi?id=216457__;!!CTRNKA9wMg0ARbw!iEOOICl7DzhvfYobmQ8MsNFAWmbqicXdjd0LYWw9uBOqwj8lai7oEODVdRJyWUEXr11A3-m7wbIX2cdpxLwiW6Tm$
> > $   [1]
> > 
> > Signed-off-by: Kuan-Ying Lee <Kuan-Ying.Lee@mediatek.com>
> > ---
> > V1 -> V2:
> >  - Implement getting allocated size of object for tag-based kasan.
> >  - Refine the kasan report.
> >  - Check if it is slab-out-of-bounds report type.
> >  - Thanks for Andrey and Dmitry suggestion.
> 
> Hi Kuan-Ying,
> 
> I came up with a few more things to fix while testing your patch and
> decided to address them myself. Please check the v3 here:
> 
> 
https://urldefense.com/v3/__https://github.com/xairy/linux/commit/012a584a9f11ba08a6051b075f7fd0a0eb54c719__;!!CTRNKA9wMg0ARbw!iEOOICl7DzhvfYobmQ8MsNFAWmbqicXdjd0LYWw9uBOqwj8lai7oEODVdRJyWUEXr11A3-m7wbIX2cdpxNwCtfpJ$ 
>  
> 
> The significant changes are to print "freed" for a slab-use-after-
> free
> and only print the region state for the Generic mode (printing it for
> Tag-Based modes doesn't work properly atm, see the comment in the
> code). The rest is clean-ups and a few added comments. See the full
> list of changes in the commit message.
> 
> Please check whether this v3 looks good to you, and then feel free to
> submit it.

It looks good to me.
I will send the v3.
Thank you.

> Thank you!
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2023-01-28 14:58 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-18  9:38 [PATCH v2] kasan: infer the requested size by scanning shadow memory Kuan-Ying Lee
2023-01-18  9:38 ` Kuan-Ying Lee
2023-01-23 21:46 ` Andrey Konovalov
2023-01-23 21:46   ` Andrey Konovalov
2023-01-28 14:58   ` Kuan-Ying Lee (李冠穎) [this message]
2023-01-28 14:58     ` Kuan-Ying Lee (李冠穎)

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=414630a65853f18c450cf1451e013b749382cbac.camel@mediatek.com \
    --to=kuan-ying.lee@mediatek.com \
    --cc=Qun-wei.Lin@mediatek.com \
    --cc=akpm@linux-foundation.org \
    --cc=andreyknvl@gmail.com \
    --cc=chinwen.chang@mediatek.com \
    --cc=dvyukov@google.com \
    --cc=glider@google.com \
    --cc=kasan-dev@googlegroups.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=linux-mm@kvack.org \
    --cc=matthias.bgg@gmail.com \
    --cc=ryabinin.a.a@gmail.com \
    --cc=vincenzo.frascino@arm.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.