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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Thu, 30 May 2024 11:42:00 -1000
From: Tejun Heo <tj@...nel.org>
To: Leon Romanovsky <leon@...nel.org>
Cc: Lai Jiangshan <jiangshanlai@...il.com>,
	Leon Romanovsky <leonro@...dia.com>,
	Zqiang <qiang.zhang1211@...il.com>, linux-kernel@...r.kernel.org,
	Gal Pressman <gal@...dia.com>, Tariq Toukan <tariqt@...dia.com>,
	RDMA mailing list <linux-rdma@...r.kernel.org>
Subject: Re: [PATCH -rc] workqueue: Reimplement UAF fix to avoid lockdep
 worning

Hello, Leon. Sorry about the delay.

On Tue, May 28, 2024 at 11:39:58AM +0300, Leon Romanovsky wrote:
> From: Leon Romanovsky <leonro@...dia.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