In the Linux kernel, the following vulnerability has been resolved:

tipc: fix use-after-free Read in tipcnamedreinit

syzbot found the following issue on:

BUG: KASAN: use-after-free in tipcnamedreinit+0x94f/0x9b0 net/tipc/name_distr.c:413 Read of size 8 at addr ffff88805299a000 by task kworker/1:9/23764

CPU: 1 PID: 23764 Comm: kworker/1:9 Not tainted 5.18.0-rc4-syzkaller-00878-g17d49e6e8012 #0 Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: events tipcnetfinalizework Call Trace: <TASK> _dumpstack lib/dumpstack.c:88 [inline] dumpstacklvl+0xcd/0x134 lib/dumpstack.c:106 printaddressdescription.constprop.0.cold+0xeb/0x495 mm/kasan/report.c:313 printreport mm/kasan/report.c:429 [inline] kasanreport.cold+0xf4/0x1c6 mm/kasan/report.c:491 tipcnamedreinit+0x94f/0x9b0 net/tipc/namedistr.c:413 tipcnetfinalize+0x234/0x3d0 net/tipc/net.c:138 processonework+0x996/0x1610 kernel/workqueue.c:2289 workerthread+0x665/0x1080 kernel/workqueue.c:2436 kthread+0x2e9/0x3a0 kernel/kthread.c:376 retfromfork+0x1f/0x30 arch/x86/entry/entry64.S:298 </TASK>

[...]

In the commit d966ddcc3821 ("tipc: fix a deadlock when flushing scheduled work"), the cancelworksync() function just to make sure ONLY the work tipcnetfinalizework() is executing/pending on any CPU completed before tipc namespace is destroyed through tipcexit_net(). But this function is not guaranteed the work is the last queued. So, the destroyed instance may be accessed in the work which will try to enqueue later.

In order to completely fix, we re-order the calling of cancelworksync() to make sure the work tipcnetfinalizework() was last queued and it must be completed by calling cancelwork_sync().