Re: [RFC PATCH v3] UML: add support for KASAN under x86_64

Johannes Berg
2022-05-27T13:15:45Z

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