On Tue, Mar 16, 2021 at 07:47:00PM +0100, Marco Elver wrote: > One thing I've just run into: "BUG: KFENCE: out-of-bounds read in > scan_block+0x6b/0x170 mm/kmemleak.c:1244" > > Probably because kmemleak is passed the rounded size for the size-class, > and not the real allocation size. Can this be fixed with > kmemleak_ignore() only called on the KFENCE guard pages? If it's only on the occasional object, you can do a kmemleak_scan_area() but some care needed as this in turn allocates memory for kmemleak internal metadata. > I'd like kmemleak to scan the valid portion of an object allocated > through KFENCE, but no further than that. > > Or do we need to fix the size if it's a kfence object: > > diff --git a/mm/kmemleak.c b/mm/kmemleak.c > index c0014d3b91c1..fe6e3ae8e8c6 100644 > --- a/mm/kmemleak.c > +++ b/mm/kmemleak.c > @@ -97,6 +97,7 @@ > #include <linux/atomic.h> > > #include <linux/kasan.h> > +#include <linux/kfence.h> > #include <linux/kmemleak.h> > #include <linux/memory_hotplug.h> > > @@ -589,7 +590,7 @@ static struct kmemleak_object *create_object(unsigned long ptr, size_t size, > atomic_set(&object->use_count, 1); > object->flags = OBJECT_ALLOCATED; > object->pointer = ptr; > - object->size = size; > + object->size = kfence_ksize((void *)ptr) ?: size; > object->excess_ref = 0; > object->min_count = min_count; > object->count = 0; /* white color initially */ > > The alternative is to call kfence_ksize() in slab_post_alloc_hook() when > calling kmemleak_alloc. One of these is probably the easiest. If kfence only works on slab objects, better to pass the right size from slab_post_alloc_hook(). If you plan to expand it later to vmalloc(), just fix the size in create_object(). -- Catalin
