CVE-2025-40003
Unknown Unknown - Not Provided
BaseFortify

Publication date: 2025-10-18

Last updated on: 2025-10-21

Assigner: kernel.org

Description
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: <IRQ> ? 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 </IRQ> ... 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---
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2025-10-18
Last Modified
2025-10-21
Generated
2026-05-07
AI Q&A
2025-10-18
EPSS Evaluated
2026-05-05
NVD
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
mscc ocelot *
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability is a use-after-free (UAF) issue in the Linux kernel's mscc ocelot network driver. It occurs because a delayed work item (ocelot->stats_work) can be rescheduled after the workqueue has been destroyed. The function cancel_delayed_work() used to cancel this work item may fail if the work is already executing, and destroy_workqueue() cannot prevent the delayed work from being re-queued after its timer expires. This leads to the workqueue being destroyed while the delayed work item is still scheduled, causing a use-after-free condition and kernel warnings. The fix replaces cancel_delayed_work() with disable_delayed_work_sync(), which ensures the delayed work is properly cancelled and completed before the workqueue is destroyed, preventing the UAF.


How can this vulnerability impact me? :

This vulnerability can cause kernel instability or crashes due to use-after-free errors in the network driver. It may lead to warnings and potential system faults when the delayed work item is rescheduled after the workqueue is destroyed. Such instability can affect system reliability and availability, especially on systems using the affected mscc ocelot driver.


How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability can be detected by monitoring kernel logs for warnings related to workqueue issues, specifically messages like "workqueue: cannot queue ocelot_check_stats_work on wq ocelot-switch-stats". Checking dmesg or system logs for such warnings can help identify the presence of the issue. Example command: `dmesg | grep ocelot_check_stats_work` or `journalctl -k | grep ocelot_check_stats_work`.


What immediate steps should I take to mitigate this vulnerability?

To mitigate this vulnerability, update the Linux kernel to a version where the fix is applied. The fix replaces cancel_delayed_work() with disable_delayed_work_sync() in the ocelot_stats_deinit() function to ensure proper cancellation and completion of delayed work items before destroying the workqueue, preventing use-after-free. Until an update is applied, avoid triggering the ocelot_stats_deinit() path or the affected workqueue operations if possible.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart