Skip to content
Fencer Intel
high 7.8

CVE-2025-37786 json

net: dsa: free routing table on probe failure

published last yr. modified 4mo ago also EUVD-2025-13037

cvss
7.8
version 3.1, NVD
cisa kev
Not listed
not in CISA's catalog
epss
0.2%
EPSS 0.2% chance of exploitation in 30 days, percentile 9%
public exploits
0
none known

Summary

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

net: dsa: free routing table on probe failure

If complete = true in dsa_tree_setup(), it means that we are the last switch of the tree which is successfully probing, and we should be setting up all switches from our probe path.

After "complete" becomes true, dsa_tree_setup_cpu_ports() or any subsequent function may fail. If that happens, the entire tree setup is in limbo: the first N-1 switches have successfully finished probing (doing nothing but having allocated persistent memory in the tree's dst->ports, and maybe dst->rtable), and switch N failed to probe, ending the tree setup process before anything is tangible from the user's PoV.

If switch N fails to probe, its memory (ports) will be freed and removed from dst->ports. However, the dst->rtable elements pointing to its ports, as created by dsa_link_touch(), will remain there, and will lead to use-after-free if dereferenced.

If dsa_tree_setup_switches() returns -EPROBE_DEFER, which is entirely possible because that is where ds->ops->setup() is, we get a kasan report like this:

================================================================== BUG: KASAN: slab-use-after-free in mv88e6xxx_setup_upstream_port+0x240/0x568 Read of size 8 at addr ffff000004f56020 by task kworker/u8:3/42

Call trace: __asan_report_load8_noabort+0x20/0x30 mv88e6xxx_setup_upstream_port+0x240/0x568 mv88e6xxx_setup+0xebc/0x1eb0 dsa_register_switch+0x1af4/0x2ae0 mv88e6xxx_register_switch+0x1b8/0x2a8 mv88e6xxx_probe+0xc4c/0xf60 mdio_probe+0x78/0xb8 really_probe+0x2b8/0x5a8 __driver_probe_device+0x164/0x298 driver_probe_device+0x78/0x258 __device_attach_driver+0x274/0x350

Allocated by task 42: __kasan_kmalloc+0x84/0xa0 __kmalloc_cache_noprof+0x298/0x490 dsa_switch_touch_ports+0x174/0x3d8 dsa_register_switch+0x800/0x2ae0 mv88e6xxx_register_switch+0x1b8/0x2a8 mv88e6xxx_probe+0xc4c/0xf60 mdio_probe+0x78/0xb8 really_probe+0x2b8/0x5a8 __driver_probe_device+0x164/0x298 driver_probe_device+0x78/0x258 __device_attach_driver+0x274/0x350

Freed by task 42: __kasan_slab_free+0x48/0x68 kfree+0x138/0x418 dsa_register_switch+0x2694/0x2ae0 mv88e6xxx_register_switch+0x1b8/0x2a8 mv88e6xxx_probe+0xc4c/0xf60 mdio_probe+0x78/0xb8 really_probe+0x2b8/0x5a8 __driver_probe_device+0x164/0x298 driver_probe_device+0x78/0x258 __device_attach_driver+0x274/0x350

The simplest way to fix the bug is to delete the routing table in its entirety. dsa_tree_setup_routing_table() has no problem in regenerating it even if we deleted links between ports other than those of switch N, because dsa_link_touch() first checks whether the port pair already exists in dst->rtable, allocating if not.

The deletion of the routing table in its entirety already exists in dsa_tree_teardown(), so refactor that into a function that can also be called from the tree setup error path.

In my analysis of the commit to blame, it is the one which added dsa_link elements to dst->rtable. Prior to that, each switch had its own ds->rtable which is freed when the switch fails to probe. But the tree is potentially persistent memory.

Patch / fix

  • Linux Linux 5.15.201, 6.1.164, 6.6.88, 6.12.25, 6.14.4, 6.15
  • linux Debian 12 6.1.164-1
  • linux Debian 14, Debian 13 6.12.25-1

debian advisories DEBIAN-CVE-2025-37786

  • linux Ubuntu 22.04 LTS 5.15.0-186.196
  • linux Ubuntu 24.04 LTS 6.8.0-100.100
  • linux-aws Ubuntu 22.04 LTS 5.15.0-1112.119
  • linux-aws Ubuntu 24.04 LTS 6.8.0-1046.49
  • linux-gcp Ubuntu 22.04 LTS 5.15.0-1112.122
  • linux-gcp Ubuntu 24.04 LTS 6.8.0-1047.50
  • linux-gke Ubuntu 22.04 LTS 5.15.0-1108.114
  • linux-gke Ubuntu 24.04 LTS 6.8.0-1043.48

ubuntu advisories UBUNTU-CVE-2025-37786

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-coco SLE Module for Confidential Computing Technical Preview 15 SP6 6.4.0-15061.28.coco15sp6.1
  • kernel-syms-coco SLE Module for Confidential Computing Technical Preview 15 SP6 6.4.0-15061.28.coco15sp6.1
  • kernel-coco_debug SLE Module for Confidential Computing Technical Preview 15 SP6 6.4.0-15061.28.coco15sp6.1
  • kernel-source-coco SLE Module for Confidential Computing Technical Preview 15 SP6 6.4.0-15061.28.coco15sp6.1
  • dtb-aarch64 openSUSE Leap 15.6 6.4.0-150600.23.60.3
  • kernel-64kb SLE Module for Basesystem 15 SP6, openSUSE Leap 15.6 6.4.0-150600.23.60.4
  • kernel-syms SLE Module for Development Tools 15 SP6, openSUSE Leap 15.6 6.4.0-150600.23.60.4
  • kernel-obs-qa openSUSE Leap 15.6 6.4.0-150600.23.60.2

suse advisories SUSE-SU-2025:02923-1SUSE-SU-2025:02538-1SUSE-SU-2025:20498-1SUSE-SU-2025:20483-1SUSE-SU-2025:02335-1SUSE-SU-2025:02333-1

Is CVE-2025-37786 in your stack? Fencer shows which of your repositories are affected as soon as an advisory lands, and opens the fix as a pull request.

Check with Fencer

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-37786 updated cvss 6.6

kernel: net: dsa: free routing table on probe failure

  • Red Hat Enterprise Linux 6 perf, kernel, python-perf, kernel-kdump, kernel-firmware, kernel-bootwrapper, +1 more
    affected: no fix planned “Out of support scope”
  • 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.19% chance of exploitation in the next 30 days, higher than 9% of all scored CVEs (FIRST EPSS, 2026-11-09).

CVSS scores

assigned by version score vector
NVD 3.1 7.8 CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Affected products

  • Linux Linux

Classification

Weakness
Technology feeds

References

Sources

Fencer Intel 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.