CVE-2025-38464: tipc: Fix use-after-free in tipc_conn_close().

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

tipc: Fix use-after-free in tipcconnclose().

syzbot reported a null-ptr-deref in tipcconnclose() during netns dismantle. [0]

tipctopsrvstop() iterates tipcnet(net)->topsrv->connidr and calls tipcconnclose() for each tipcconn.

The problem is that tipcconnclose() is called after releasing the IDR lock.

At the same time, there might be tipcconnrecvwork() running and it could call tipcconnclose() for the same tipcconn and release its last ->kref.

Once we release the IDR lock in tipctopsrvstop(), there is no guarantee that the tipcconn is alive.

Let's hold the ref before releasing the lock and put the ref after tipcconnclose() in tipctopsrvstop().

[0]: BUG: KASAN: use-after-free in tipcconnclose+0x122/0x140 net/tipc/topsrv.c:165 Read of size 8 at addr ffff888099305a08 by task kworker/u4:3/435

CPU: 0 PID: 435 Comm: kworker/u4:3 Not tainted 4.19.204-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: netns cleanupnet Call Trace: dumpstack lib/dumpstack.c:77 [inline] dumpstack+0x1fc/0x2ef lib/dumpstack.c:118 printaddressdescription.cold+0x54/0x219 mm/kasan/report.c:256 kasanreporterror.cold+0x8a/0x1b9 mm/kasan/report.c:354 kasanreport mm/kasan/report.c:412 [inline] asanreportload8noabort+0x88/0x90 mm/kasan/report.c:433 tipcconnclose+0x122/0x140 net/tipc/topsrv.c:165 tipctopsrvstop net/tipc/topsrv.c:701 [inline] tipctopsrvexitnet+0x27b/0x5c0 net/tipc/topsrv.c:722 opsexitlist+0xa5/0x150 net/core/netnamespace.c:153 cleanupnet+0x3b4/0x8b0 net/core/netnamespace.c:553 processonework+0x864/0x1570 kernel/workqueue.c:2153 workerthread+0x64c/0x1130 kernel/workqueue.c:2296 kthread+0x33f/0x460 kernel/kthread.c:259 retfromfork+0x24/0x30 arch/x86/entry/entry64.S:415

Allocated by task 23: kmemcachealloctrace+0x12f/0x380 mm/slab.c:3625 kmalloc include/linux/slab.h:515 [inline] kzalloc include/linux/slab.h:709 [inline] tipcconnalloc+0x43/0x4f0 net/tipc/topsrv.c:192 tipctopsrvaccept+0x1b5/0x280 net/tipc/topsrv.c:470 processonework+0x864/0x1570 kernel/workqueue.c:2153 workerthread+0x64c/0x1130 kernel/workqueue.c:2296 kthread+0x33f/0x460 kernel/kthread.c:259 retfromfork+0x24/0x30 arch/x86/entry/entry64.S:415

Freed by task 23: cachefree mm/slab.c:3503 [inline] kfree+0xcc/0x210 mm/slab.c:3822 tipcconnkrefrelease net/tipc/topsrv.c:150 [inline] krefput include/linux/kref.h:70 [inline] connput+0x2cd/0x3a0 net/tipc/topsrv.c:155 processonework+0x864/0x1570 kernel/workqueue.c:2153 workerthread+0x64c/0x1130 kernel/workqueue.c:2296 kthread+0x33f/0x460 kernel/kthread.c:259 retfromfork+0x24/0x30 arch/x86/entry/entry64.S:415

The buggy address belongs to the object at ffff888099305a00 which belongs to the cache kmalloc-512 of size 512 The buggy address is located 8 bytes inside of 512-byte region [ffff888099305a00, ffff888099305c00) The buggy address belongs to the page: page:ffffea000264c140 count:1 mapcount:0 mapping:ffff88813bff0940 index:0x0 flags: 0xfff00000000100(slab) raw: 00fff00000000100 ffffea00028b6b88 ffffea0002cd2b08 ffff88813bff0940 raw: 0000000000000000 ffff888099305000 0000000100000006 0000000000000000 page dumped because: kasan: bad access detected

Memory state around the buggy address: ffff888099305900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff888099305980: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff888099305a00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff888099305a80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff888099305b00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb