On Wed, 7 Sept 2022 at 07:53, Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote: > > > > The buggy address belongs to the object at ffff888017576600 > > > > which belongs to the cache kmalloc-192 of size 192 > > > > The buggy address is located 184 bytes inside of > > > > 192-byte region [ffff888017576600, ffff8880175766c0) > > > > > > At offset 184 of a 192-byte region. > > > > > > So what's wrong with doing that? Does KASAN have an off-by-one? > > > > Hi Andrew, all, > > > > This is a bug in FIND_NEXT_BIT(). It should be > > if (idx >= sz / BITS_PER_LONG) \ > > goto out; \ > > > > instead of > > if (idx > sz / BITS_PER_LONG) \ > > goto out; \ > > > > The fix is in bitmap-for-next, expected to be in -next by tomorrow. > > Sorry for the noise. > > OK... but why is KASAN reporting a bad access from an area > which appears to be OK? Hi Andrew, Good point. Filed https://bugzilla.kernel.org/show_bug.cgi?id=216457 for this. Copy-pasting description below: KASAN says: ================================================================== BUG: KASAN: slab-out-of-bounds in _find_next_bit+0x143/0x160 lib/find_bit.c:109 Read of size 8 at addr ffff8880175766b8 by task kworker/1:1/26 ... The buggy address belongs to the object at ffff888017576600 which belongs to the cache kmalloc-192 of size 192 The buggy address is located 184 bytes inside of 192-byte region [ffff888017576600, ffff8880175766c0) ... Memory state around the buggy address: >ffff888017576680: 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc ^ ================================================================== This "address is located 184 bytes inside of 192-byte region" is confusing b/c it does not look like an out-of-bounds access. What happens here is that the allocation request was for 184 bytes, so the last 8 bytes in the 192-byte slab are poisoned. But KASAN does not store the requested size in the object header, so it just prints the full slab size everywhere. User-space ASAN does store 48-bit requested size in the header. But KASAN uses additional bytes in the header for: struct kasan_alloc_meta { depot_stack_handle_t aux_stack[2]; So we don't have space for requested size w/o increasing header size (currently should be 16 bytes). We could either try to infer requested size from the shadow (count poisoned bytes at the end); or improve wording of the message at least to make it clear that 192 is just full slab size. For context see: https://lore.kernel.org/all/20220906173154.6f2664c8fc6b83470c5dfea1@xxxxxxxxxxxxxxxxxxxx/
