* [PATCH] kasan: add test for SLAB_TYPESAFE_BY_RCU quarantine skipping
@ 2025-07-28 15:25 Jann Horn
2025-07-29 16:14 ` Vlastimil Babka
0 siblings, 1 reply; 3+ messages in thread
From: Jann Horn @ 2025-07-28 15:25 UTC (permalink / raw)
To: Andrey Ryabinin, Alexander Potapenko, Andrey Konovalov,
Dmitry Vyukov, Vincenzo Frascino, Andrew Morton
Cc: Vlastimil Babka, kasan-dev, linux-mm, linux-kernel, Jann Horn
Verify that KASAN does not quarantine objects in SLAB_TYPESAFE_BY_RCU slabs
if CONFIG_SLUB_RCU_DEBUG is off.
Suggested-by: Andrey Konovalov <andreyknvl@gmail.com>
Signed-off-by: Jann Horn <jannh@google.com>
---
Feel free to either take this as a separate commit or squash it into the
preceding "[PATCH] kasan: skip quarantine if object is still accessible
under RCU".
I tested this by running KASAN kunit tests for x86-64 with KASAN
and tracing manually enabled; there are two failing tests but those
seem unrelated (kasan_memchr is unexpectedly not detecting some
accesses, and kasan_strings is also failing).
---
mm/kasan/kasan_test_c.c | 36 ++++++++++++++++++++++++++++++++++++
1 file changed, 36 insertions(+)
diff --git a/mm/kasan/kasan_test_c.c b/mm/kasan/kasan_test_c.c
index 5f922dd38ffa..15d3d82041bf 100644
--- a/mm/kasan/kasan_test_c.c
+++ b/mm/kasan/kasan_test_c.c
@@ -1073,6 +1073,41 @@ static void kmem_cache_rcu_uaf(struct kunit *test)
kmem_cache_destroy(cache);
}
+/*
+ * Check that SLAB_TYPESAFE_BY_RCU objects are immediately reused when
+ * CONFIG_SLUB_RCU_DEBUG is off, and stay at the same address.
+ */
+static void kmem_cache_rcu_reuse(struct kunit *test)
+{
+ char *p, *p2;
+ struct kmem_cache *cache;
+
+ KASAN_TEST_NEEDS_CONFIG_OFF(test, CONFIG_SLUB_RCU_DEBUG);
+
+ cache = kmem_cache_create("test_cache", 16, 0, SLAB_TYPESAFE_BY_RCU,
+ NULL);
+ KUNIT_ASSERT_NOT_ERR_OR_NULL(test, cache);
+
+ p = kmem_cache_alloc(cache, GFP_KERNEL);
+ if (!p) {
+ kunit_err(test, "Allocation failed: %s\n", __func__);
+ kmem_cache_destroy(cache);
+ return;
+ }
+
+ kmem_cache_free(cache, p);
+ p2 = kmem_cache_alloc(cache, GFP_KERNEL);
+ if (!p2) {
+ kunit_err(test, "Allocation failed: %s\n", __func__);
+ kmem_cache_destroy(cache);
+ return;
+ }
+ KUNIT_ASSERT_PTR_EQ(test, p, p2);
+
+ kmem_cache_free(cache, p2);
+ kmem_cache_destroy(cache);
+}
+
static void kmem_cache_double_destroy(struct kunit *test)
{
struct kmem_cache *cache;
@@ -2098,6 +2133,7 @@ static struct kunit_case kasan_kunit_test_cases[] = {
KUNIT_CASE(kmem_cache_double_free),
KUNIT_CASE(kmem_cache_invalid_free),
KUNIT_CASE(kmem_cache_rcu_uaf),
+ KUNIT_CASE(kmem_cache_rcu_reuse),
KUNIT_CASE(kmem_cache_double_destroy),
KUNIT_CASE(kmem_cache_accounted),
KUNIT_CASE(kmem_cache_bulk),
---
base-commit: 0df7d6c9705b283d5b71ee0ae86ead05bd3a55a9
change-id: 20250728-kasan-tsbrcu-noquarantine-test-5c723367e056
prerequisite-change-id: 20250723-kasan-tsbrcu-noquarantine-e207bb990e24:v1
prerequisite-patch-id: 4fab9d3a121bfcaacc32a40f606b7c04e0c6fdd0
--
Jann Horn <jannh@google.com>
^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: [PATCH] kasan: add test for SLAB_TYPESAFE_BY_RCU quarantine skipping
2025-07-28 15:25 [PATCH] kasan: add test for SLAB_TYPESAFE_BY_RCU quarantine skipping Jann Horn
@ 2025-07-29 16:14 ` Vlastimil Babka
2025-07-29 16:35 ` Jann Horn
0 siblings, 1 reply; 3+ messages in thread
From: Vlastimil Babka @ 2025-07-29 16:14 UTC (permalink / raw)
To: Jann Horn, Andrey Ryabinin, Alexander Potapenko, Andrey Konovalov,
Dmitry Vyukov, Vincenzo Frascino, Andrew Morton
Cc: kasan-dev, linux-mm, linux-kernel
On 7/28/25 17:25, Jann Horn wrote:
> Verify that KASAN does not quarantine objects in SLAB_TYPESAFE_BY_RCU slabs
> if CONFIG_SLUB_RCU_DEBUG is off.
>
> Suggested-by: Andrey Konovalov <andreyknvl@gmail.com>
> Signed-off-by: Jann Horn <jannh@google.com>
> ---
> Feel free to either take this as a separate commit or squash it into the
> preceding "[PATCH] kasan: skip quarantine if object is still accessible
> under RCU".
>
> I tested this by running KASAN kunit tests for x86-64 with KASAN
> and tracing manually enabled; there are two failing tests but those
> seem unrelated (kasan_memchr is unexpectedly not detecting some
> accesses, and kasan_strings is also failing).
> ---
> mm/kasan/kasan_test_c.c | 36 ++++++++++++++++++++++++++++++++++++
> 1 file changed, 36 insertions(+)
>
> diff --git a/mm/kasan/kasan_test_c.c b/mm/kasan/kasan_test_c.c
> index 5f922dd38ffa..15d3d82041bf 100644
> --- a/mm/kasan/kasan_test_c.c
> +++ b/mm/kasan/kasan_test_c.c
> @@ -1073,6 +1073,41 @@ static void kmem_cache_rcu_uaf(struct kunit *test)
> kmem_cache_destroy(cache);
> }
>
> +/*
> + * Check that SLAB_TYPESAFE_BY_RCU objects are immediately reused when
> + * CONFIG_SLUB_RCU_DEBUG is off, and stay at the same address.
> + */
> +static void kmem_cache_rcu_reuse(struct kunit *test)
> +{
> + char *p, *p2;
> + struct kmem_cache *cache;
> +
> + KASAN_TEST_NEEDS_CONFIG_OFF(test, CONFIG_SLUB_RCU_DEBUG);
> +
> + cache = kmem_cache_create("test_cache", 16, 0, SLAB_TYPESAFE_BY_RCU,
> + NULL);
> + KUNIT_ASSERT_NOT_ERR_OR_NULL(test, cache);
Hmm is there anything inherent in kunit that keeps the test pinned to the
same cpu? Otherwise I think you'll need here
migrate_disable();
> + p = kmem_cache_alloc(cache, GFP_KERNEL);
> + if (!p) {
> + kunit_err(test, "Allocation failed: %s\n", __func__);
> + kmem_cache_destroy(cache);
> + return;
> + }
> +
> + kmem_cache_free(cache, p);
> + p2 = kmem_cache_alloc(cache, GFP_KERNEL);
and here (or later)
migrate_enable();
> + if (!p2) {
> + kunit_err(test, "Allocation failed: %s\n", __func__);
> + kmem_cache_destroy(cache);
> + return;
> + }
> + KUNIT_ASSERT_PTR_EQ(test, p, p2);
Otherwise the cpu slab caching of SLUB and a migration could mean this won't
hold as you'll get object from another slab.
> + kmem_cache_free(cache, p2);
> + kmem_cache_destroy(cache);
> +}
> +
> static void kmem_cache_double_destroy(struct kunit *test)
> {
> struct kmem_cache *cache;
> @@ -2098,6 +2133,7 @@ static struct kunit_case kasan_kunit_test_cases[] = {
> KUNIT_CASE(kmem_cache_double_free),
> KUNIT_CASE(kmem_cache_invalid_free),
> KUNIT_CASE(kmem_cache_rcu_uaf),
> + KUNIT_CASE(kmem_cache_rcu_reuse),
> KUNIT_CASE(kmem_cache_double_destroy),
> KUNIT_CASE(kmem_cache_accounted),
> KUNIT_CASE(kmem_cache_bulk),
>
> ---
> base-commit: 0df7d6c9705b283d5b71ee0ae86ead05bd3a55a9
> change-id: 20250728-kasan-tsbrcu-noquarantine-test-5c723367e056
> prerequisite-change-id: 20250723-kasan-tsbrcu-noquarantine-e207bb990e24:v1
> prerequisite-patch-id: 4fab9d3a121bfcaacc32a40f606b7c04e0c6fdd0
>
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] kasan: add test for SLAB_TYPESAFE_BY_RCU quarantine skipping
2025-07-29 16:14 ` Vlastimil Babka
@ 2025-07-29 16:35 ` Jann Horn
0 siblings, 0 replies; 3+ messages in thread
From: Jann Horn @ 2025-07-29 16:35 UTC (permalink / raw)
To: Vlastimil Babka
Cc: Andrey Ryabinin, Alexander Potapenko, Andrey Konovalov,
Dmitry Vyukov, Vincenzo Frascino, Andrew Morton, kasan-dev,
linux-mm, linux-kernel
On Tue, Jul 29, 2025 at 6:14 PM Vlastimil Babka <vbabka@suse.cz> wrote:
> On 7/28/25 17:25, Jann Horn wrote:
> > Verify that KASAN does not quarantine objects in SLAB_TYPESAFE_BY_RCU slabs
> > if CONFIG_SLUB_RCU_DEBUG is off.
> >
> > Suggested-by: Andrey Konovalov <andreyknvl@gmail.com>
> > Signed-off-by: Jann Horn <jannh@google.com>
> > ---
> > Feel free to either take this as a separate commit or squash it into the
> > preceding "[PATCH] kasan: skip quarantine if object is still accessible
> > under RCU".
> >
> > I tested this by running KASAN kunit tests for x86-64 with KASAN
> > and tracing manually enabled; there are two failing tests but those
> > seem unrelated (kasan_memchr is unexpectedly not detecting some
> > accesses, and kasan_strings is also failing).
> > ---
> > mm/kasan/kasan_test_c.c | 36 ++++++++++++++++++++++++++++++++++++
> > 1 file changed, 36 insertions(+)
> >
> > diff --git a/mm/kasan/kasan_test_c.c b/mm/kasan/kasan_test_c.c
> > index 5f922dd38ffa..15d3d82041bf 100644
> > --- a/mm/kasan/kasan_test_c.c
> > +++ b/mm/kasan/kasan_test_c.c
> > @@ -1073,6 +1073,41 @@ static void kmem_cache_rcu_uaf(struct kunit *test)
> > kmem_cache_destroy(cache);
> > }
> >
> > +/*
> > + * Check that SLAB_TYPESAFE_BY_RCU objects are immediately reused when
> > + * CONFIG_SLUB_RCU_DEBUG is off, and stay at the same address.
> > + */
> > +static void kmem_cache_rcu_reuse(struct kunit *test)
> > +{
> > + char *p, *p2;
> > + struct kmem_cache *cache;
> > +
> > + KASAN_TEST_NEEDS_CONFIG_OFF(test, CONFIG_SLUB_RCU_DEBUG);
> > +
> > + cache = kmem_cache_create("test_cache", 16, 0, SLAB_TYPESAFE_BY_RCU,
> > + NULL);
> > + KUNIT_ASSERT_NOT_ERR_OR_NULL(test, cache);
>
> Hmm is there anything inherent in kunit that keeps the test pinned to the
> same cpu? Otherwise I think you'll need here
>
> migrate_disable();
Oops, right, good point.
> > + p = kmem_cache_alloc(cache, GFP_KERNEL);
> > + if (!p) {
> > + kunit_err(test, "Allocation failed: %s\n", __func__);
> > + kmem_cache_destroy(cache);
> > + return;
> > + }
> > +
> > + kmem_cache_free(cache, p);
> > + p2 = kmem_cache_alloc(cache, GFP_KERNEL);
>
> and here (or later)
>
> migrate_enable();
>
> > + if (!p2) {
> > + kunit_err(test, "Allocation failed: %s\n", __func__);
> > + kmem_cache_destroy(cache);
> > + return;
> > + }
> > + KUNIT_ASSERT_PTR_EQ(test, p, p2);
>
> Otherwise the cpu slab caching of SLUB and a migration could mean this won't
> hold as you'll get object from another slab.
Yeah...
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2025-07-29 16:35 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-07-28 15:25 [PATCH] kasan: add test for SLAB_TYPESAFE_BY_RCU quarantine skipping Jann Horn
2025-07-29 16:14 ` Vlastimil Babka
2025-07-29 16:35 ` Jann Horn
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).