CVE-2025-38211: RDMA/iwcm: Fix use-after-free of work objects after cm_id destruction

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

RDMA/iwcm: Fix use-after-free of work objects after cmid destruction

The commit 59c68ac31e15 ("iwcm: free cmid resources on the last deref") simplified cmid resource management by freeing cmid once all references to the cmid were removed. The references are removed either upon completion of iwcm event handlers or when the application destroys the cmid. This commit introduced the use-after-free condition where cmidprivate object could still be in use by event handler works during the destruction of cmid. The commit aee2424246f9 ("RDMA/iwcm: Fix a use-after-free related to destroying CM IDs") addressed this use-after- free by flushing all pending works at the cmid destruction.

However, still another use-after-free possibility remained. It happens with the work objects allocated for each cmidpriv within allocworkentries() during cmid creation, and subsequently freed in deallocworkentries() once all references to the cmid are removed. If the cmid's last reference is decremented in the event handler work, the work object for the work itself gets removed, and causes the use- after-free BUG below:

BUG: KASAN: slab-use-after-free in pwqactivatework+0x1ff/0x250 Read of size 8 at addr ffff88811f9cf800 by task kworker/u16:1/147091

CPU: 2 UID: 0 PID: 147091 Comm: kworker/u16:1 Not tainted 6.15.0-rc2+ #27 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014 Workqueue: 0x0 (iwcmwq) Call Trace: <TASK> dumpstacklvl+0x6a/0x90 printreport+0x174/0x554 ? virtaddrvalid+0x208/0x430 ? pwqactivatework+0x1ff/0x250 kasanreport+0xae/0x170 ? pwqactivatework+0x1ff/0x250 pwqactivatework+0x1ff/0x250 pwqdecnrinflight+0x8c5/0xfb0 processonework+0xc11/0x1460 ? pfxprocessonework+0x10/0x10 ? assignwork+0x16c/0x240 workerthread+0x5ef/0xfd0 ? pfxworkerthread+0x10/0x10 kthread+0x3b0/0x770 ? pfxkthread+0x10/0x10 ? rcuiswatching+0x11/0xb0 ? rawspinunlockirq+0x24/0x50 ? rcuiswatching+0x11/0xb0 ? pfxkthread+0x10/0x10 retfromfork+0x30/0x70 ? pfxkthread+0x10/0x10 retfromforkasm+0x1a/0x30 </TASK>

Allocated by task 147416: kasansavestack+0x2c/0x50 kasansavetrack+0x10/0x30 kasankmalloc+0xa6/0xb0 allocworkentries+0xa9/0x260 [iwcm] iwcmconnect+0x23/0x4a0 [iwcm] rdmaconnectlocked+0xbfd/0x1920 [rdmacm] nvmerdmacmhandler+0x8e5/0x1b60 [nvmerdma] cmacmeventhandler+0xae/0x320 [rdmacm] cmaworkhandler+0x106/0x1b0 [rdmacm] processonework+0x84f/0x1460 workerthread+0x5ef/0xfd0 kthread+0x3b0/0x770 retfromfork+0x30/0x70 retfromforkasm+0x1a/0x30

Freed by task 147091: kasansavestack+0x2c/0x50 kasansavetrack+0x10/0x30 kasansavefreeinfo+0x37/0x60 kasanslabfree+0x4b/0x70 kfree+0x13a/0x4b0 deallocworkentries+0x125/0x1f0 [iwcm] iwcmderefid+0x6f/0xa0 [iwcm] cmworkhandler+0x136/0x1ba0 [iwcm] processonework+0x84f/0x1460 workerthread+0x5ef/0xfd0 kthread+0x3b0/0x770 retfromfork+0x30/0x70 retfromforkasm+0x1a/0x30

Last potentially related work creation: kasansavestack+0x2c/0x50 kasanrecordauxstack+0xa3/0xb0 queuework+0x2ff/0x1390 queueworkon+0x67/0xc0 cmeventhandler+0x46a/0x820 [iwcm] siwcmupcall+0x330/0x650 [siw] siwcmworkhandler+0x6b9/0x2b20 [siw] processonework+0x84f/0x1460 workerthread+0x5ef/0xfd0 kthread+0x3b0/0x770 retfromfork+0x30/0x70 retfromforkasm+0x1a/0x30

This BUG is reproducible by repeating the blktests test case nvme/061 for the rdma transport and the siw driver.

To avoid the use-after-free of cmidprivate work objects, ensure that the last reference to the cmid is decremented not in the event handler works, but in the cmid destruction context. For that purpose, mo ---truncated---