Re: [PATCH -rc] workqueue: Reimplement UAF fix to avoid lockdep worning

Tejun Heo
2024-05-30T21:42:03Z

Hello, Leon. Sorry about the delay.

On Tue, May 28, 2024 at 11:39:58AM +0300, Leon Romanovsky wrote:
> From: Leon Romanovsky <leonro@nvidia.com>
>
> The commit 643445531829 ("workqueue: Fix UAF report by KASAN in
> pwq_release_workfn()") causes to the following lockdep warning.

KASAN warning?

> [ 1818.839405] ==================================================================
> [ 1818.840636] BUG: KASAN: slab-use-after-free in lockdep_register_key+0x707/0x810
> [ 1818.841827] Read of size 8 at addr ffff888156864928 by task systemd-udevd/71399
...
> [ 1818.846493] Call Trace:
> [ 1818.846981] <TASK>
> [ 1818.847439] dump_stack_lvl+0x7e/0xc0
> [ 1818.848089] print_report+0xc1/0x600
> [ 1818.850978] kasan_report+0xb9/0xf0
> [ 1818.852381] lockdep_register_key+0x707/0x810
> [ 1818.855329] alloc_workqueue+0x466/0x1800

Can you please map this to the source line?

> [ 1818.857997] ib_mad_init_device+0x809/0x1760 [ib_core]

...

> [ 1818.907242] Allocated by task 1:
> [ 1818.907819] kasan_save_stack+0x20/0x40
> [ 1818.908512] kasan_save_track+0x10/0x30
> [ 1818.909173] __kasan_slab_alloc+0x51/0x60
> [ 1818.909849] kmem_cache_alloc_noprof+0x139/0x3f0
> [ 1818.910608] getname_flags+0x4f/0x3c0
> [ 1818.911236] do_sys_openat2+0xd3/0x150
> [ 1818.911878] __x64_sys_openat+0x11f/0x1d0
> [ 1818.912554] do_syscall_64+0x6d/0x140
> [ 1818.913189] entry_SYSCALL_64_after_hwframe+0x4b/0x53
> [ 1818.913996]
> [ 1818.914359] Freed by task 1:
> [ 1818.914897] kasan_save_stack+0x20/0x40
> [ 1818.915553] kasan_save_track+0x10/0x30
> [ 1818.916210] kasan_save_free_info+0x37/0x50
> [ 1818.916911] poison_slab_object+0x10c/0x190
> [ 1818.917606] __kasan_slab_free+0x11/0x30
> [ 1818.918271] kmem_cache_free+0x12c/0x460
> [ 1818.918939] do_sys_openat2+0x102/0x150
> [ 1818.919586] __x64_sys_openat+0x11f/0x1d0
> [ 1818.920264] do_syscall_64+0x6d/0x140
> [ 1818.920899] entry_SYSCALL_64_after_hwframe+0x4b/0x53
> [ 1818.921699]
> [ 1818.922059] The buggy address belongs to the object at ffff888156864400
> [ 1818.922059] which belongs to the cache names_cache of size 4096

This is a dcache name. I'm a bit lost on how we're hitting this.

Thanks.

--
tejun