| Message ID | 20191112065313.7060-1-walter-zh.wu@mediatek.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | fix the missing underflow in memory operation function | expand |
On 11/12/19 9:53 AM, Walter Wu wrote: > Test negative size in memmove in order to verify whether it correctly > get KASAN report. > > Casting negative numbers to size_t would indeed turn up as a large > size_t, so it will have out-of-bounds bug and be detected by KASAN. > > Signed-off-by: Walter Wu <walter-zh.wu@mediatek.com> > Reviewed-by: Dmitry Vyukov <dvyukov@google.com> Reviewed-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
On Fri, 2019-11-22 at 06:21 +0800, Andrey Ryabinin wrote: > > On 11/12/19 9:53 AM, Walter Wu wrote: > > Test negative size in memmove in order to verify whether it correctly > > get KASAN report. > > > > Casting negative numbers to size_t would indeed turn up as a large > > size_t, so it will have out-of-bounds bug and be detected by KASAN. > > > > Signed-off-by: Walter Wu <walter-zh.wu@mediatek.com> > > Reviewed-by: Dmitry Vyukov <dvyukov@google.com> > > Reviewed-by: Andrey Ryabinin <aryabinin@virtuozzo.com> Hi Andrey, Dmitry, Andrew, Would you tell me why this patch-sets don't merge into linux-next tree? We lost something? Thanks for your help. Walter
On Thu, 30 Jan 2020 11:43:58 +0800 Walter Wu <walter-zh.wu@mediatek.com> wrote: > On Fri, 2019-11-22 at 06:21 +0800, Andrey Ryabinin wrote: > > > > On 11/12/19 9:53 AM, Walter Wu wrote: > > > Test negative size in memmove in order to verify whether it correctly > > > get KASAN report. > > > > > > Casting negative numbers to size_t would indeed turn up as a large > > > size_t, so it will have out-of-bounds bug and be detected by KASAN. > > > > > > Signed-off-by: Walter Wu <walter-zh.wu@mediatek.com> > > > Reviewed-by: Dmitry Vyukov <dvyukov@google.com> > > > > Reviewed-by: Andrey Ryabinin <aryabinin@virtuozzo.com> > > Hi Andrey, Dmitry, Andrew, > > Would you tell me why this patch-sets don't merge into linux-next tree? > We lost something? > In response to [1/2] Andrey said "So let's keep this code as this" and you said "I will send a new v5 patch tomorrow". So we're awaiting a v5 patchset?
On Thu, 2020-01-30 at 18:16 -0800, Andrew Morton wrote: > On Thu, 30 Jan 2020 11:43:58 +0800 Walter Wu <walter-zh.wu@mediatek.com> wrote: > > > On Fri, 2019-11-22 at 06:21 +0800, Andrey Ryabinin wrote: > > > > > > On 11/12/19 9:53 AM, Walter Wu wrote: > > > > Test negative size in memmove in order to verify whether it correctly > > > > get KASAN report. > > > > > > > > Casting negative numbers to size_t would indeed turn up as a large > > > > size_t, so it will have out-of-bounds bug and be detected by KASAN. > > > > > > > > Signed-off-by: Walter Wu <walter-zh.wu@mediatek.com> > > > > Reviewed-by: Dmitry Vyukov <dvyukov@google.com> > > > > > > Reviewed-by: Andrey Ryabinin <aryabinin@virtuozzo.com> > > > > Hi Andrey, Dmitry, Andrew, > > > > Would you tell me why this patch-sets don't merge into linux-next tree? > > We lost something? > > > > In response to [1/2] Andrey said "So let's keep this code as this" and > you said "I will send a new v5 patch tomorrow". So we're awaiting a v5 > patchset? > Hi Andrew, The [1/2] patch discussion shows below. Thanks for Dimitry help to explain it. So that v4 patchset got Andrey's signature. Because I see Andrey said "But I see you point now. No objections to the patch in that case." @Andrey, if I have an incorrect understanding, please let me know. Thanks for your help. https://lkml.org/lkml/2019/11/21/1019 https://lkml.org/lkml/2019/11/21/1020 Walter
diff --git a/lib/test_kasan.c b/lib/test_kasan.c index 49cc4d570a40..06942cf585cc 100644 --- a/lib/test_kasan.c +++ b/lib/test_kasan.c @@ -283,6 +283,23 @@ static noinline void __init kmalloc_oob_in_memset(void) kfree(ptr); } +static noinline void __init kmalloc_memmove_invalid_size(void) +{ + char *ptr; + size_t size = 64; + + pr_info("invalid size in memmove\n"); + ptr = kmalloc(size, GFP_KERNEL); + if (!ptr) { + pr_err("Allocation failed\n"); + return; + } + + memset((char *)ptr, 0, 64); + memmove((char *)ptr, (char *)ptr + 4, -2); + kfree(ptr); +} + static noinline void __init kmalloc_uaf(void) { char *ptr; @@ -773,6 +790,7 @@ static int __init kmalloc_tests_init(void) kmalloc_oob_memset_4(); kmalloc_oob_memset_8(); kmalloc_oob_memset_16(); + kmalloc_memmove_invalid_size(); kmalloc_uaf(); kmalloc_uaf_memset(); kmalloc_uaf2();