CVE-2025-40003 in Linux
Summary
by MITRE • 10/18/2025
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 cancel_delayed_work() in ocelot_stats_deinit() to cancel the cyclic delayed work item ocelot->stats_work. However, cancel_delayed_work() may fail to cancel the work item if it is already executing. While destroy_workqueue() 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 ocelot_check_stats_work() function. This limitation exists because the delayed work item is only enqueued into the work queue after its timer expires. Before the timer expiration, destroy_workqueue() has no visibility of this pending work item. Once the work queue appears empty, destroy_workqueue() proceeds with destruction. When the timer eventually expires, the delayed work item gets queued again, leading to the following warning:
workqueue: cannot queue ocelot_check_stats_work on wq ocelot-switch-stats WARNING: CPU: 2 PID: 0 at kernel/workqueue.c:2255 __queue_work+0x875/0xaf0 ... RIP: 0010:__queue_work+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: ? kasan_report+0xc6/0xf0 ? __pfx_delayed_work_timer_fn+0x10/0x10 ? __pfx_delayed_work_timer_fn+0x10/0x10 call_timer_fn+0x25/0x1c0 __run_timer_base.part.0+0x3be/0x8c0 ? __pfx_delayed_work_timer_fn+0x10/0x10 ? rcu_sched_clock_irq+0xb06/0x27d0 ? __pfx___run_timer_base.part.0+0x10/0x10 ? try_to_wake_up+0xb15/0x1960 ? _raw_spin_lock_irq+0x80/0xe0 ? __pfx__raw_spin_lock_irq+0x10/0x10 tmigr_handle_remote_up+0x603/0x7e0 ? __pfx_tmigr_handle_remote_up+0x10/0x10 ? sched_balance_trigger+0x1c0/0x9f0 ? sched_tick+0x221/0x5a0 ? _raw_spin_lock_irq+0x80/0xe0 ? __pfx__raw_spin_lock_irq+0x10/0x10 ? tick_nohz_handler+0x339/0x440 ? __pfx_tmigr_handle_remote_up+0x10/0x10 __walk_groups.isra.0+0x42/0x150 tmigr_handle_remote+0x1f4/0x2e0 ? __pfx_tmigr_handle_remote+0x10/0x10 ? ktime_get+0x60/0x140 ? lapic_next_event+0x11/0x20 ? clockevents_program_event+0x1d4/0x2a0 ? hrtimer_interrupt+0x322/0x780 handle_softirqs+0x16a/0x550 irq_exit_rcu+0xaf/0xe0 sysvec_apic_timer_interrupt+0x70/0x80 ...
The following diagram reveals the cause of the above warning:
CPU 0 (remove) | CPU 1 (delayed work callback) mscc_ocelot_remove() | ocelot_deinit() | ocelot_check_stats_work() ocelot_stats_deinit() | cancel_delayed_work()| ... | queue_delayed_work() destroy_workqueue() | (wait a time) | __queue_work() //UAF
The above scenario actually constitutes a UAF vulnerability.
The ocelot_stats_deinit() is only invoked when initialization failure or resource destruction, so we must ensure that any delayed work items cannot be rescheduled.
Replace cancel_delayed_work() with disable_delayed_work_sync() 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: ocelot_stats_deinit() 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---
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 02/13/2026
The vulnerability described in CVE-2025-40003 affects the Linux kernel's networking subsystem, specifically within the Marvell Switch Controller (MSCC) Ocelot driver. This issue arises from improper handling of delayed work items during device removal, creating a use-after-free (UAF) condition that can lead to system instability or potential exploitation. The flaw is rooted in the interaction between workqueue management functions and the lifecycle of hardware-specific statistics collection mechanisms.
The technical flaw occurs when the driver attempts to clean up resources during device removal through the `ocelot_stats_deinit()` function. While this function calls `cancel_delayed_work()` to terminate the cyclic `ocelot->stats_work` delayed work item, this approach is insufficient due to a race condition inherent in the workqueue subsystem. The `cancel_delayed_work()` function only prevents new scheduling of the work item but cannot guarantee that an already executing instance completes before the workqueue destruction. When `destroy_workqueue()` is invoked, it waits for pending work items but cannot observe delayed work items that are scheduled to run after their timer expires, as these items are not visible until their timer triggers.
This race condition creates a scenario where a delayed work item can be rescheduled after `destroy_workqueue()` has completed its wait phase, leading to a UAF condition when the work item attempts to access freed memory. The kernel warning demonstrates that `__queue_work()` fails because it tries to queue a work item to a workqueue that has already been destroyed, indicating that the delayed work item is attempting to re-execute after its parent structure has been deallocated. The call trace reveals that the problematic execution path involves timer functions and workqueue management components, confirming the timing issue.
The vulnerability is classified as a use-after-free under CWE-416 and represents a classic race condition in concurrent programming. The specific attack surface involves kernel memory management and device driver cleanup operations within the networking subsystem. This issue can be exploited to cause system crashes or potentially achieve privilege escalation if an attacker can control the timing and memory layout of the freed structure. The problem is particularly concerning in embedded systems or network infrastructure where continuous operation and reliability are critical.
The fix implemented replaces `cancel_delayed_work()` with `cancel_delayed_work_sync()` to ensure proper synchronization. This change guarantees that any currently executing work item completes before the workqueue is destroyed, preventing the UAF condition. The solution addresses the root cause by ensuring that all pending work items, including those that may be scheduled to run after their timer expires, are properly terminated before resource deallocation occurs. The fix is considered safe because `ocelot_stats_deinit()` is called from a process context without holding locks that could cause deadlocks with the delayed work item execution path.
The vulnerability was identified through static analysis, which is consistent with modern kernel security practices that emphasize automated detection of race conditions and memory management issues. The fix aligns with the ATT&CK framework's system and information integrity tactics, as it prevents unauthorized modification of kernel memory structures. The remediation approach demonstrates proper kernel development practices for managing workqueue lifecycles and handling concurrent access patterns in device drivers. This fix exemplifies the importance of understanding the full lifecycle of kernel work items and ensuring proper synchronization primitives are used during resource cleanup operations.