On Thu, Nov 23, 2023 at 1:39 AM Hyeonggon Yoo <42.hyeyoo@xxxxxxxxx> wrote: > > On Thu, Nov 23, 2023 at 8:12 AM <andrey.konovalov@xxxxxxxxx> wrote: > > > > From: Andrey Konovalov <andreyknvl@xxxxxxxxxx> > > > > When both KASAN and slub_debug are enabled, when a free object is being > > prepared in setup_object, slub_debug poisons the object data before KASAN > > initializes its per-object metadata. > > > > Right now, in setup_object, KASAN only initializes the alloc metadata, > > which is always stored outside of the object. slub_debug is aware of > > this and it skips poisoning and checking that memory area. > > > > However, with the following patch in this series, KASAN also starts > > initializing its free medata in setup_object. As this metadata might be > > stored within the object, this initialization might overwrite the > > slub_debug poisoning. This leads to slub_debug reports. > > > > Thus, skip checking slub_debug poisoning of the object data area that > > overlaps with the in-object KASAN free metadata. > > > > Also make slub_debug poisoning of tail kmalloc redzones more precise when > > KASAN is enabled: slub_debug can still poison and check the tail kmalloc > > allocation area that comes after the KASAN free metadata. > > > > Signed-off-by: Andrey Konovalov <andreyknvl@xxxxxxxxxx> > > Thank you for looking at this quickly! > Unfortunately the problem isn't fixed yet with the patch. > > I applied this on top of linux-next and built a kernel with the same config, > it is still stuck at boot. Ah, this is caused by a buggy version of "kasan: improve free meta storage in Generic KASAN", which made its way into linux-next. Reverting that patch should fix the issue. My patch that you bisected to exposes the buggy behavior. Thanks!
