Skip to content

Commit 56bdf83

Browse files
thejhakpm00
authored andcommitted
kasan: skip quarantine if object is still accessible under RCU
Currently, enabling KASAN masks bugs where a lockless lookup path gets a pointer to a SLAB_TYPESAFE_BY_RCU object that might concurrently be recycled and is insufficiently careful about handling recycled objects: KASAN puts freed objects in SLAB_TYPESAFE_BY_RCU slabs onto its quarantine queues, even when it can't actually detect UAF in these objects, and the quarantine prevents fast recycling. When I introduced CONFIG_SLUB_RCU_DEBUG, my intention was that enabling CONFIG_SLUB_RCU_DEBUG should cause KASAN to mark such objects as freed after an RCU grace period and put them on the quarantine, while disabling CONFIG_SLUB_RCU_DEBUG should allow such objects to be reused immediately; but that hasn't actually been working. I discovered such a UAF bug involving SLAB_TYPESAFE_BY_RCU yesterday; I could only trigger this bug in a KASAN build by disabling CONFIG_SLUB_RCU_DEBUG and applying this patch. Link: https://lkml.kernel.org/r/20250723-kasan-tsbrcu-noquarantine-v1-1-846c8645976c@google.com Signed-off-by: Jann Horn <jannh@google.com> Acked-by: Vlastimil Babka <vbabka@suse.cz> Reviewed-by: Alexander Potapenko <glider@google.com> Acked-by: Andrey Konovalov <andreyknvl@gmail.com> Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com> Cc: Dmitriy Vyukov <dvyukov@google.com> Cc: Vincenzo Frascino <vincenzo.frascino@arm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
1 parent d171b10 commit 56bdf83

File tree

1 file changed

+18
-7
lines changed

1 file changed

+18
-7
lines changed

mm/kasan/common.c

Lines changed: 18 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -230,16 +230,12 @@ static bool check_slab_allocation(struct kmem_cache *cache, void *object,
230230
}
231231

232232
static inline void poison_slab_object(struct kmem_cache *cache, void *object,
233-
bool init, bool still_accessible)
233+
bool init)
234234
{
235235
void *tagged_object = object;
236236

237237
object = kasan_reset_tag(object);
238238

239-
/* RCU slabs could be legally used after free within the RCU period. */
240-
if (unlikely(still_accessible))
241-
return;
242-
243239
kasan_poison(object, round_up(cache->object_size, KASAN_GRANULE_SIZE),
244240
KASAN_SLAB_FREE, init);
245241

@@ -261,7 +257,22 @@ bool __kasan_slab_free(struct kmem_cache *cache, void *object, bool init,
261257
if (!kasan_arch_is_ready() || is_kfence_address(object))
262258
return false;
263259

264-
poison_slab_object(cache, object, init, still_accessible);
260+
/*
261+
* If this point is reached with an object that must still be
262+
* accessible under RCU, we can't poison it; in that case, also skip the
263+
* quarantine. This should mostly only happen when CONFIG_SLUB_RCU_DEBUG
264+
* has been disabled manually.
265+
*
266+
* Putting the object on the quarantine wouldn't help catch UAFs (since
267+
* we can't poison it here), and it would mask bugs caused by
268+
* SLAB_TYPESAFE_BY_RCU users not being careful enough about object
269+
* reuse; so overall, putting the object into the quarantine here would
270+
* be counterproductive.
271+
*/
272+
if (still_accessible)
273+
return false;
274+
275+
poison_slab_object(cache, object, init);
265276

266277
/*
267278
* If the object is put into quarantine, do not let slab put the object
@@ -519,7 +530,7 @@ bool __kasan_mempool_poison_object(void *ptr, unsigned long ip)
519530
if (check_slab_allocation(slab->slab_cache, ptr, ip))
520531
return false;
521532

522-
poison_slab_object(slab->slab_cache, ptr, false, false);
533+
poison_slab_object(slab->slab_cache, ptr, false);
523534
return true;
524535
}
525536

0 commit comments

Comments
 (0)