Messages in this thread | | | From | Dmitry Vyukov <> | Date | Fri, 27 May 2022 15:18:34 +0200 | Subject | Re: [RFC PATCH v3] UML: add support for KASAN under x86_64 |
| |
On Fri, 27 May 2022 at 15:15, Johannes Berg <johannes@sipsolutions.net> wrote: > > On Fri, 2022-05-27 at 15:09 +0200, Dmitry Vyukov wrote: > > > I did note (this is more for kasan-dev@) that the "freed by" is fairly > > > much useless when using kfree_rcu(), it might be worthwhile to annotate > > > that somehow, so the stack trace is recorded by kfree_rcu() already, > > > rather than just showing the RCU callback used for that. > > > > KASAN is doing it for several years now, see e.g.: > > https://groups.google.com/g/syzkaller-bugs/c/eTW9zom4O2o/m/_v7cOo2RFwAJ > > > > Hm. It didn't for me:
Please post a full report with line numbers and kernel version.
> > BUG: KASAN: use-after-free in ieee80211_vif_use_reserved_context+0x32d/0x40f [mac80211] > > Read of size 4 at addr 0000000065c73340 by task kworker/u2:1/17 > > Yes. > > > CPU: 0 PID: 17 Comm: kworker/u2:1 Tainted: G O 5.18.0-rc1 #5 > > Workqueue: phy0 ieee80211_chswitch_work [mac80211] > > Stack: > > 60ba783f 00000000 10000c268f4e 60ba783f > > 60e60847 70dc9928 719f6e99 00000000 > > 71883b20 60bb0b42 60bb0b19 65c73340 > > Call Trace: > > [<600447ea>] show_stack+0x13e/0x14d > > [<60bb0b42>] dump_stack_lvl+0x29/0x2e > > [<602ef7c0>] print_report+0x15d/0x60b > > [<602efdc0>] kasan_report+0x98/0xbd > > [<602f0cc2>] __asan_report_load4_noabort+0x1b/0x1d > > [<719f6e99>] ieee80211_vif_use_reserved_context+0x32d/0x40f [mac80211] > > This is the user, it just got freed during a function call a few lines > up. > > > Allocated by task 16: > > save_stack_trace+0x2e/0x30 > > stack_trace_save+0x81/0x9b > > kasan_save_stack+0x2d/0x54 > > kasan_set_track+0x34/0x3e > > ____kasan_kmalloc+0x8d/0x99 > > __kasan_kmalloc+0x10/0x12 > > __kmalloc+0x1f6/0x20b > > ieee80211_alloc_chanctx+0xdc/0x35f [mac80211] > > This makes sense too. > > > Freed by task 8: > > save_stack_trace+0x2e/0x30 > > stack_trace_save+0x81/0x9b > > kasan_save_stack+0x2d/0x54 > > kasan_set_track+0x34/0x3e > > kasan_set_free_info+0x33/0x44 > > ____kasan_slab_free+0x12b/0x149 > > __kasan_slab_free+0x19/0x1b > > slab_free_freelist_hook+0x10b/0x16a > > kfree+0x10d/0x1fa > > kvfree+0x38/0x3a > > rcu_process_callbacks+0x2c5/0x349 > > This is the RCU callback. > > > Last potentially related work creation: > > save_stack_trace+0x2e/0x30 > > stack_trace_save+0x81/0x9b > > kasan_save_stack+0x2d/0x54 > > __kasan_record_aux_stack+0xd5/0xe2 > > kasan_record_aux_stack_noalloc+0x12/0x14 > > insert_work+0x50/0xd7 > > __queue_work+0x805/0x95c > > queue_work_on+0xba/0x131 > > call_usermodehelper_exec+0x242/0x361 > > kobject_uevent_env+0xe46/0xeaf > > kobject_uevent+0x12/0x14 > > driver_register+0x37e/0x38d > > pcie_port_service_register+0x19d/0x1a5 > > This stuff is completely unrelated. > > > The buggy address belongs to the object at 0000000065c73300 > > which belongs to the cache kmalloc-192 of size 192 > > The buggy address is located 64 bytes inside of > > 192-byte region [0000000065c73300, 0000000065c733c0) > > > > and that's it? > > johannes > > -- > You received this message because you are subscribed to the Google Groups "kasan-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an email to kasan-dev+unsubscribe@googlegroups.com. > To view this discussion on the web visit https://groups.google.com/d/msgid/kasan-dev/6fa1ebe49b8d574fb1c82aefeeb54439d9c98750.camel%40sipsolutions.net.
| |