Re: [PATCH v3] kasan: infer allocation size by scanning metadata

On Sat, 2023-01-28 at 23:37 +0100, Andrey Konovalov wrote:

/On Sat, Jan 28, 2023 at 4:00 PM Kuan-Ying Lee
[off-list ref] wrote:

quoted

From: Andrey Konovalov <redacted>

Ah, I think you need to reset the commit author before sending, so
that the patch gets recorded as authored by you.

Got it.
Will do in v4.

quoted

Make KASAN scan metadata to infer the requested allocation size
instead of
printing cache->object_size.

This patch fixes confusing slab-out-of-bounds reports as reported
in:

https://urldefense.com/v3/__https://bugzilla.kernel.org/show_bug.cgi?id=216457__;!!CTRNKA9wMg0ARbw!mXW4Z05dX9YXnBYWxw-OOBYutqBM0JFoaApK61lFCSldptsVi0JEtWNSU9uaSnXbGq5oiKCBfyHLFFtEmY5uFgDl$ 

quoted

 

As an example of the confusing behavior, the report below hints
that the
allocation size was 192, while the kernel actually called
kmalloc(184):

==================================================================
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:
 ffff888017576580: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
 ffff888017576600: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

quoted

ffff888017576680: 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc

                                        ^
 ffff888017576700: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
 ffff888017576780: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
==================================================================

With this patch, the report shows:

==================================================================
...
The buggy address belongs to the object at ffff888017576600
 which belongs to the cache kmalloc-192 of size 192
The buggy address is located 0 bytes to the right of
 allocated 184-byte region [ffff888017576600, ffff8880175766b8)
...
==================================================================

Also report slab use-after-free bugs as "slab-use-after-free" and
print
"freed" instead of "allocated" in the report when describing the
accessed
memory region.

Also improve the metadata-related comment in
kasan_find_first_bad_addr
and use addr_has_metadata across KASAN code instead of open-coding
KASAN_SHADOW_START checks.

Link: 
https://urldefense.com/v3/__https://bugzilla.kernel.org/show_bug.cgi?id=216457__;!!CTRNKA9wMg0ARbw!mXW4Z05dX9YXnBYWxw-OOBYutqBM0JFoaApK61lFCSldptsVi0JEtWNSU9uaSnXbGq5oiKCBfyHLFFtEmY5uFgDl$ 
 
Co-developed-by: Andrey Konovalov <andreyknvl@gmail.com>
Signed-off-by: Kuan-Ying Lee <redacted>

Or change the Co-developed-by/Signed-off-by tags.

I don't mind either approach.

Thanks!

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel