[PATCH] kasan: fix KASAN unit tests for tag-based KASAN

8 views
Skip to first unread message

Walter Wu

unread,
Apr 20, 2020, 9:40:14 PM4/20/20
to Andrey Ryabinin, Alexander Potapenko, Dmitry Vyukov, Matthias Brugger, Andrey Konovalov, Andrew Morton, kasa...@googlegroups.com, linu...@kvack.org, linux-...@vger.kernel.org, linux-ar...@lists.infradead.org, wsd_upstream, linux-m...@lists.infradead.org, Walter Wu
When we use tag-based KASAN, then KASAN unit tests don't detect
out-of-bounds memory access. Because with tag-based KASAN the state
of each 16 aligned bytes of memory is encoded in one shadow byte
and the shadow value is tag of pointer, so we need to read next
shadow byte, the shadow value is not equal to tag of pointer,
then tag-based KASAN will detect out-of-bounds memory access.

Signed-off-by: Walter Wu <walter...@mediatek.com>
Cc: Andrey Ryabinin <arya...@virtuozzo.com>
Cc: Dmitry Vyukov <dvy...@google.com>
Cc: Alexander Potapenko <gli...@google.com>
Cc: Matthias Brugger <matthi...@gmail.com>
Cc: Andrey Konovalov <andre...@google.com>
Cc: Andrew Morton <ak...@linux-foundation.org>
---
lib/test_kasan.c | 62 ++++++++++++++++++++++++++++++++++++++++++------
1 file changed, 55 insertions(+), 7 deletions(-)

diff --git a/lib/test_kasan.c b/lib/test_kasan.c
index e3087d90e00d..a164f6b47fe5 100644
--- a/lib/test_kasan.c
+++ b/lib/test_kasan.c
@@ -40,7 +40,12 @@ static noinline void __init kmalloc_oob_right(void)
return;
}

+#ifdef CONFIG_KASAN_GENERIC
ptr[size] = 'x';
+#else
+ ptr[size + 5] = 'x';
+#endif
+
kfree(ptr);
}

@@ -92,7 +97,12 @@ static noinline void __init kmalloc_pagealloc_oob_right(void)
return;
}

+#ifdef CONFIG_KASAN_GENERIC
ptr[size] = 0;
+#else
+ ptr[size + 6] = 0;
+#endif
+
kfree(ptr);
}

@@ -162,7 +172,11 @@ static noinline void __init kmalloc_oob_krealloc_more(void)
return;
}

+#ifdef CONFIG_KASAN_GENERIC
ptr2[size2] = 'x';
+#else
+ ptr2[size2 + 13] = 'x';
+#endif
kfree(ptr2);
}

@@ -180,7 +194,12 @@ static noinline void __init kmalloc_oob_krealloc_less(void)
kfree(ptr1);
return;
}
+
+#ifdef CONFIG_KASAN_GENERIC
ptr2[size2] = 'x';
+#else
+ ptr2[size2 + 2] = 'x';
+#endif
kfree(ptr2);
}

@@ -216,7 +235,11 @@ static noinline void __init kmalloc_oob_memset_2(void)
return;
}

+#ifdef CONFIG_KASAN_GENERIC
memset(ptr+7, 0, 2);
+#else
+ memset(ptr+15, 0, 2);
+#endif
kfree(ptr);
}

@@ -232,7 +255,11 @@ static noinline void __init kmalloc_oob_memset_4(void)
return;
}

+#ifdef CONFIG_KASAN_GENERIC
memset(ptr+5, 0, 4);
+#else
+ memset(ptr+15, 0, 4);
+#endif
kfree(ptr);
}

@@ -249,7 +276,11 @@ static noinline void __init kmalloc_oob_memset_8(void)
return;
}

+#ifdef CONFIG_KASAN_GENERIC
memset(ptr+1, 0, 8);
+#else
+ memset(ptr+15, 0, 8);
+#endif
kfree(ptr);
}

@@ -265,7 +296,11 @@ static noinline void __init kmalloc_oob_memset_16(void)
return;
}

+#ifdef CONFIG_KASAN_GENERIC
memset(ptr+1, 0, 16);
+#else
+ memset(ptr+15, 0, 16);
+#endif
kfree(ptr);
}

@@ -281,7 +316,11 @@ static noinline void __init kmalloc_oob_in_memset(void)
return;
}

+#ifdef CONFIG_KASAN_GENERIC
memset(ptr, 0, size+5);
+#else
+ memset(ptr, 0, size+7);
+#endif
kfree(ptr);
}

@@ -415,7 +454,11 @@ static noinline void __init kmem_cache_oob(void)
return;
}

+#ifdef CONFIG_KASAN_GENERIC
*p = p[size];
+#else
+ *p = p[size + 8];
+#endif
kmem_cache_free(cache, p);
kmem_cache_destroy(cache);
}
@@ -497,6 +540,11 @@ static noinline void __init copy_user_test(void)
char __user *usermem;
size_t size = 10;
int unused;
+#ifdef CONFIG_KASAN_GENERIC
+ size_t oob_size = 1;
+#else
+ size_t oob_size = 7;
+#endif

kmem = kmalloc(size, GFP_KERNEL);
if (!kmem)
@@ -512,25 +560,25 @@ static noinline void __init copy_user_test(void)
}

pr_info("out-of-bounds in copy_from_user()\n");
- unused = copy_from_user(kmem, usermem, size + 1);
+ unused = copy_from_user(kmem, usermem, size + oob_size);

pr_info("out-of-bounds in copy_to_user()\n");
- unused = copy_to_user(usermem, kmem, size + 1);
+ unused = copy_to_user(usermem, kmem, size + oob_size);

pr_info("out-of-bounds in __copy_from_user()\n");
- unused = __copy_from_user(kmem, usermem, size + 1);
+ unused = __copy_from_user(kmem, usermem, size + oob_size);

pr_info("out-of-bounds in __copy_to_user()\n");
- unused = __copy_to_user(usermem, kmem, size + 1);
+ unused = __copy_to_user(usermem, kmem, size + oob_size);

pr_info("out-of-bounds in __copy_from_user_inatomic()\n");
- unused = __copy_from_user_inatomic(kmem, usermem, size + 1);
+ unused = __copy_from_user_inatomic(kmem, usermem, size + oob_size);

pr_info("out-of-bounds in __copy_to_user_inatomic()\n");
- unused = __copy_to_user_inatomic(usermem, kmem, size + 1);
+ unused = __copy_to_user_inatomic(usermem, kmem, size + oob_size);

pr_info("out-of-bounds in strncpy_from_user()\n");
- unused = strncpy_from_user(kmem, usermem, size + 1);
+ unused = strncpy_from_user(kmem, usermem, size + oob_size);

vm_munmap((unsigned long)usermem, PAGE_SIZE);
kfree(kmem);
--
2.18.0

Dmitry Vyukov

unread,
Apr 21, 2020, 7:56:25 AM4/21/20
to Walter Wu, David Gow, Brendan Higgins, Patricia Alfonso, Andrey Ryabinin, Alexander Potapenko, Matthias Brugger, Andrey Konovalov, Andrew Morton, kasan-dev, Linux-MM, LKML, Linux ARM, wsd_upstream, linux-m...@lists.infradead.org
On Tue, Apr 21, 2020 at 3:40 AM Walter Wu <walter...@mediatek.com> wrote:
>
> When we use tag-based KASAN, then KASAN unit tests don't detect
> out-of-bounds memory access. Because with tag-based KASAN the state
> of each 16 aligned bytes of memory is encoded in one shadow byte
> and the shadow value is tag of pointer, so we need to read next
> shadow byte, the shadow value is not equal to tag of pointer,
> then tag-based KASAN will detect out-of-bounds memory access.
>
> Signed-off-by: Walter Wu <walter...@mediatek.com>
> Cc: Andrey Ryabinin <arya...@virtuozzo.com>
> Cc: Dmitry Vyukov <dvy...@google.com>
> Cc: Alexander Potapenko <gli...@google.com>
> Cc: Matthias Brugger <matthi...@gmail.com>
> Cc: Andrey Konovalov <andre...@google.com>
> Cc: Andrew Morton <ak...@linux-foundation.org>
> ---
> lib/test_kasan.c | 62 ++++++++++++++++++++++++++++++++++++++++++------
> 1 file changed, 55 insertions(+), 7 deletions(-)
>
> diff --git a/lib/test_kasan.c b/lib/test_kasan.c
> index e3087d90e00d..a164f6b47fe5 100644
> --- a/lib/test_kasan.c
> +++ b/lib/test_kasan.c
> @@ -40,7 +40,12 @@ static noinline void __init kmalloc_oob_right(void)
> return;
> }

Hi Walter,

This would be great to have!
But I am concerned about these series that port KASAN tests to KUNIT:
https://lkml.org/lkml/2020/4/17/1144
I suspect it will be one large merge conflict. Not sure what is the
proper way to resovle this. I've added authors to CC.


> +#ifdef CONFIG_KASAN_GENERIC
> ptr[size] = 'x';
> +#else
> + ptr[size + 5] = 'x';
> +#endif
> +

For this particular snippet I think we can reduce amount of idef'ery
and amount of non-compiled code in each configuration with something
like:

ptr[size + 5] = 'x';
if (ENABLED(CONFIG_KASAN_GENERIC))
ptr[size] = 'x';

One check runs always (it should pass in both configs, right?). The
only only in GENERIC, but it's C-level if rather than preprocessor.
KUNIT should make 2 bugs per test easily expressable (and testable).
> --
> You received this message because you are subscribed to the Google Groups "kasan-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to kasan-dev+...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/kasan-dev/20200421014007.6012-1-walter-zh.wu%40mediatek.com.

Walter Wu

unread,
Apr 21, 2020, 8:26:50 AM4/21/20
to Dmitry Vyukov, David Gow, Brendan Higgins, Patricia Alfonso, Andrey Ryabinin, Alexander Potapenko, Matthias Brugger, Andrey Konovalov, Andrew Morton, kasan-dev, Linux-MM, LKML, Linux ARM, wsd_upstream, linux-m...@lists.infradead.org
Hi Dmitry,
Yes, it should have conflicts. Thanks for your reminder.
>
> > +#ifdef CONFIG_KASAN_GENERIC
> > ptr[size] = 'x';
> > +#else
> > + ptr[size + 5] = 'x';
> > +#endif
> > +
>
> For this particular snippet I think we can reduce amount of idef'ery
> and amount of non-compiled code in each configuration with something
> like:
>
> ptr[size + 5] = 'x';
> if (ENABLED(CONFIG_KASAN_GENERIC))
> ptr[size] = 'x';
>
> One check runs always (it should pass in both configs, right?). The

There is a problem, With generic KASAN it may trigger two KASAN reports.
if we change it like:

if (ENABLED(CONFIG_KASAN_GENERIC))
ptr[size] = 'x';
else
ptr[size + 5] = 'x';

Dmitry Vyukov

unread,
Apr 21, 2020, 9:01:46 AM4/21/20
to Walter Wu, David Gow, Brendan Higgins, Patricia Alfonso, Andrey Ryabinin, Alexander Potapenko, Matthias Brugger, Andrey Konovalov, Andrew Morton, kasan-dev, Linux-MM, LKML, Linux ARM, wsd_upstream, linux-m...@lists.infradead.org
Why is this a problem? If there are 2, fine. KUNIT can check that if
we expect 2, there are indeed 2.
> To view this discussion on the web visit https://groups.google.com/d/msgid/kasan-dev/1587472005.5870.7.camel%40mtksdccf07.

Walter Wu

unread,
Apr 21, 2020, 9:37:59 AM4/21/20
to Dmitry Vyukov, David Gow, Brendan Higgins, Patricia Alfonso, Andrey Ryabinin, Alexander Potapenko, Matthias Brugger, Andrey Konovalov, Andrew Morton, kasan-dev, Linux-MM, LKML, Linux ARM, wsd_upstream, linux-m...@lists.infradead.org
Sorry, I originally assume my patch doesn't include in KUNIT. so I think
there is a problem. but I know your meaning. Can my patch upstream
first?
Reply all
Reply to author
Forward
0 new messages