CVE-2025-40003: net: mscc: ocelot: Fix use-after-free caused by cyclic delayed work

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

net: mscc: ocelot: Fix use-after-free caused by cyclic delayed work

The origin code calls canceldelayedwork() in ocelotstatsdeinit() to cancel the cyclic delayed work item ocelot->statswork. However, canceldelayedwork() may fail to cancel the work item if it is already executing. While destroyworkqueue() does wait for all pending work items in the work queue to complete before destroying the work queue, it cannot prevent the delayed work item from being rescheduled within the ocelotcheckstatswork() function. This limitation exists because the delayed work item is only enqueued into the work queue after its timer expires. Before the timer expiration, destroyworkqueue() has no visibility of this pending work item. Once the work queue appears empty, destroyworkqueue() proceeds with destruction. When the timer eventually expires, the delayed work item gets queued again, leading to the following warning:

workqueue: cannot queue ocelotcheckstatswork on wq ocelot-switch-stats WARNING: CPU: 2 PID: 0 at kernel/workqueue.c:2255 queuework+0x875/0xaf0 ... RIP: 0010:queuework+0x875/0xaf0 ... RSP: 0018:ffff88806d108b10 EFLAGS: 00010086 RAX: 0000000000000000 RBX: 0000000000000101 RCX: 0000000000000027 RDX: 0000000000000027 RSI: 0000000000000004 RDI: ffff88806d123e88 RBP: ffffffff813c3170 R08: 0000000000000000 R09: ffffed100da247d2 R10: ffffed100da247d1 R11: ffff88806d123e8b R12: ffff88800c00f000 R13: ffff88800d7285c0 R14: ffff88806d0a5580 R15: ffff88800d7285a0 FS: 0000000000000000(0000) GS:ffff8880e5725000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fe18e45ea10 CR3: 0000000005e6c000 CR4: 00000000000006f0 Call Trace: <IRQ> ? kasanreport+0xc6/0xf0 ? pfxdelayedworktimerfn+0x10/0x10 ? pfxdelayedworktimerfn+0x10/0x10 calltimerfn+0x25/0x1c0 runtimerbase.part.0+0x3be/0x8c0 ? pfxdelayedworktimerfn+0x10/0x10 ? rcuschedclockirq+0xb06/0x27d0 ? pfxruntimerbase.part.0+0x10/0x10 ? trytowakeup+0xb15/0x1960 ? rawspinlockirq+0x80/0xe0 ? pfxrawspinlockirq+0x10/0x10 tmigrhandleremoteup+0x603/0x7e0 ? pfxtmigrhandleremoteup+0x10/0x10 ? schedbalancetrigger+0x1c0/0x9f0 ? schedtick+0x221/0x5a0 ? rawspinlockirq+0x80/0xe0 ? pfxrawspinlockirq+0x10/0x10 ? ticknohzhandler+0x339/0x440 ? pfxtmigrhandleremoteup+0x10/0x10 walkgroups.isra.0+0x42/0x150 tmigrhandleremote+0x1f4/0x2e0 ? pfxtmigrhandleremote+0x10/0x10 ? ktimeget+0x60/0x140 ? lapicnextevent+0x11/0x20 ? clockeventsprogramevent+0x1d4/0x2a0 ? hrtimerinterrupt+0x322/0x780 handlesoftirqs+0x16a/0x550 irqexitrcu+0xaf/0xe0 sysvecapictimerinterrupt+0x70/0x80 </IRQ> ...

The following diagram reveals the cause of the above warning:

CPU 0 (remove) | CPU 1 (delayed work callback) msccocelotremove() | ocelotdeinit() | ocelotcheckstatswork() ocelotstatsdeinit() | canceldelayedwork()| ... | queuedelayedwork() destroyworkqueue() | (wait a time) | queuework() //UAF

The above scenario actually constitutes a UAF vulnerability.

The ocelotstatsdeinit() is only invoked when initialization failure or resource destruction, so we must ensure that any delayed work items cannot be rescheduled.

Replace canceldelayedwork() with disabledelayedworksync() to guarantee proper cancellation of the delayed work item and ensure completion of any currently executing work before the workqueue is deallocated.

A deadlock concern was considered: ocelotstatsdeinit() is called in a process context and is not holding any locks that the delayed work item might also need. Therefore, the use of the sync() variant is safe here.

This bug was identified through static analysis. To reproduce the issue and validate the fix, I simulated ocelot-swit ---truncated---