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: > 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 _______________________________________________ linux-um mailing list linux-um@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-um
