Skip to content
Fencer Vulns
no cvss —

CVE-2025-40003 json

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

published 2025-10-18 12 mo ago modified 2026-10-30 10 d ago also EUVD-2025-34986

cvss
—
not scored
cisa kev
Not listed
not in CISA's catalog
epss
0.3%
EPSS 0.3% chance of exploitation in 30 days, percentile 17%
public exploits
0
none known

Summary

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---

Patch / fix

  • Linux Linux 6.1.191, 6.6.160, 6.12.54, 6.17.4, 6.18
  • linux Debian 13 6.12.57-1
  • linux Debian 14 6.17.6-1

debian advisories DEBIAN-CVE-2025-40003

  • linux Ubuntu 25.10 6.17.0-14.14
  • linux-aws Ubuntu 25.10 6.17.0-1007.7
  • linux-gcp Ubuntu 25.10 6.17.0-1007.7
  • linux-azure Ubuntu 25.10 6.17.0-1008.8
  • linux-raspi Ubuntu 25.10 6.17.0-1008.8
  • linux-riscv Ubuntu 25.10 6.17.0-14.14.1
  • linux-oracle Ubuntu 25.10 6.17.0-1007.7
  • linux-aws-6.17 Ubuntu 24.04 LTS 6.17.0-1007.7~24.04.1

ubuntu advisories UBUNTU-CVE-2025-40003

Ubuntu security data © Canonical Ltd., from https://github.com/canonical/ubuntu-security-notices via OSV; changed: normalised to fixed package versions per release. CC BY-SA 4.0

  • kernel-rt Linux Micro 6.2 6.12.0-160000.8.1
  • kernel-64kb SLES 16.0, Linux Micro 6.2, SLES for SAP applications 16.0 6.12.0-160000.8.1
  • kernel-source SLES 16.0, Linux Micro 6.2, SLES for SAP applications 16.0 6.12.0-160000.8.1
  • kernel-default SLES 16.0, SLE High Availability Extension 16.0, Linux Micro 6.2 +1 more 6.12.0-160000.8.1
  • kernel-default-base SLES 16.0, Linux Micro 6.2, SLES for SAP applications 16.0 6.12.0-160000.8.1.160000.2.5
  • kernel-syms SLES 16.0, Linux Micro Extras 6.2, SLES for SAP applications 16.0 6.12.0-160000.8.1
  • kernel-obs-qa SLES for SAP applications 16.0, SLES 16.0 6.12.0-160000.8.1
  • kernel-kvmsmall SLES for SAP applications 16.0, SLES 16.0 6.12.0-160000.8.1

suse advisories SUSE-SU-2026:20012-1SUSE-SU-2026:20015-1SUSE-SU-2026:20021-1SUSE-SU-2026:20562-1

  • kernel-source-longterm openSUSE Tumbleweed 6.18.16-1.1
  • kernel-rt openSUSE Leap 16.0 6.12.0-160000.8.1
  • dtb-aarch64 openSUSE Leap 16.0 6.12.0-160000.8.1
  • kernel-64kb openSUSE Leap 16.0 6.12.0-160000.8.1
  • kernel-syms openSUSE Leap 16.0 6.12.0-160000.8.1
  • kernel-obs-qa openSUSE Leap 16.0 6.12.0-160000.8.1
  • kernel-source openSUSE Leap 16.0 6.12.0-160000.8.1
  • kernel-default openSUSE Leap 16.0 6.12.0-160000.8.1

opensuse advisories openSUSE-SU-2026:10301-1openSUSE-SU-2025:20172-1openSUSE-SU-2025:15671-1

  • kernel Azure Linux 3.0 6.6.161.1-1

azure linux advisories AZL-68582

Azure Linux vulnerability data, Copyright (c) Microsoft Corporation, from https://github.com/microsoft/AzureLinuxVulnerabilityData via OSV, under the MIT licence; changed: normalised to fixed package versions per release. MIT

Vendor advisories

What the vendors themselves say about their products: affected, fixed or not affected, and what to do.

red hat product security vex CVE-2025-40003 updated

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

  • Red Hat Enterprise Linux 6 perf, kernel, python-perf, kernel-kdump, kernel-firmware, kernel-bootwrapper, +1 more Red Hat Enterprise Linux 7 perf, kernel, bpftool, kernel-rt, python-perf, kernel-kdump, +8 more Red Hat Enterprise Linux 8 perf, kernel, bpftool, kernel-rt, kernel-core, kernel-tools, +29 more Red Hat Enterprise Linux 9 rv, perf, rtla, kernel, bpftool, libperf, +83 more Red Hat Enterprise Linux 10 kernel
    not affected: vulnerable code not present

Red Hat CSAF VEX © Red Hat, Inc., from https://security.access.redhat.com/data/csaf/v2/vex/; changed: reduced to product statuses and remediations. CC BY 4.0 · csaf

Exploit prediction

0.26% chance of exploitation in the next 30 days, higher than 17% of all scored CVEs (FIRST EPSS, 2026-11-08).

Affected products

  • Linux Linux

Classification

Technology feeds

References

Sources

Fencer Vulns keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.