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

Tejun Heo
2024-06-03T20:10:39Z

Hello, again, Leon.

Re-reading the warning, I'm not sure this is a bug on workqueue side.

On Fri, May 31, 2024 at 06:48:51AM +0300, Leon Romanovsky wrote:
> [ 1233.554381] ==================================================================
> [ 1233.555215] BUG: KASAN: slab-use-after-free in lockdep_register_key+0x707/0x810
> [ 1233.555983] Read of size 8 at addr ffff88811f1d8928 by task test-ovs-bond-m/10149
> [ 1233.556774]
> [ 1233.557020] CPU: 0 PID: 10149 Comm: test-ovs-bond-m Not tainted 6.10.0-rc1_external_1613e604df0c #1
> [ 1233.557951] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
> [ 1233.559044] Call Trace:
> [ 1233.559367] <TASK>
> [ 1233.559653] dump_stack_lvl+0x7e/0xc0
> [ 1233.560078] print_report+0xc1/0x600
> [ 1233.561975] kasan_report+0xb9/0xf0
> [ 1233.562872] lockdep_register_key+0x707/0x810
> [ 1233.564799] alloc_workqueue+0x466/0x1800
> [ 1233.567627] mlx5_pagealloc_init+0x7d/0x180 [mlx5_core]
> [ 1233.568322] mlx5_mdev_init+0x482/0xad0 [mlx5_core]
> [ 1233.569387] probe_one+0x11d/0xc80 [mlx5_core]

So, this is saying that alloc_workqueue() allocated a name during lockdep
initialization. This is before pwq init or anything else complicated
happening. It just allocated the workqueue struct and called into
lockep_register_key(&wq->key).

> [ 1233.599979] Allocated by task 9589:
> [ 1233.600382] kasan_save_stack+0x20/0x40
> [ 1233.600828] kasan_save_track+0x10/0x30
> [ 1233.601265] __kasan_kmalloc+0x77/0x90
> [ 1233.601696] kernfs_iop_get_link+0x61/0x5a0
> [ 1233.602181] vfs_readlink+0x1ab/0x320
> [ 1233.602605] do_readlinkat+0x1cb/0x290
> [ 1233.602610] __x64_sys_readlinkat+0x92/0xf0
> [ 1233.602612] do_syscall_64+0x6d/0x140
> [ 1233.605196] entry_SYSCALL_64_after_hwframe+0x4b/0x53
> [ 1233.605731]
> [ 1233.605986] Freed by task 9589:
> [ 1233.606373] kasan_save_stack+0x20/0x40
> [ 1233.606801] kasan_save_track+0x10/0x30
> [ 1233.607232] kasan_save_free_info+0x37/0x50
> [ 1233.607695] poison_slab_object+0x10c/0x190
> [ 1233.608161] __kasan_slab_free+0x11/0x30
> [ 1233.608604] kfree+0x11b/0x340
> [ 1233.608970] vfs_readlink+0x120/0x320
> [ 1233.609413] do_readlinkat+0x1cb/0x290
> [ 1233.609849] __x64_sys_readlinkat+0x92/0xf0
> [ 1233.610308] do_syscall_64+0x6d/0x140
> [ 1233.610741] entry_SYSCALL_64_after_hwframe+0x4b/0x53

And KASAN is reporting use-after-free on a completely unrelated VFS object.
I can't tell for sure from the logs alone but lockdep_register_key()
iterates entries in the hashtable trying to find whether the key is a
duplicate and it could be that that walk is triggering the use-after-free
warning. If so, it doesn't really have much to do with workqueue. The
corruption happened elsewhere and workqueue just happens to traverse the
hashtable afterwards.

Thanks.

--
tejun