The upstream Linux kernel maintainers have pushed a sharp, surgical fix for an out-of-bounds memory access in the SJA1105 DSA driver, tracked as CVE-2025-22107. Left unpatched, the bug can trigger kernel oops or panic when a switch configuration table entry is removed, potentially crashing systems that rely on the BroadR‑Reach/Automotive Ethernet switch hardware. The patch — which landed in the mainline and multiple stable trees — corrects an off‑by‑one arithmetic error in the deletion routine, eliminating the unsafe memmove that touched memory beyond the array’s end.

While this is a Linux kernel vulnerability, it matters to Windows‑centric IT pros who manage mixed environments, network appliances, or even WSL instances with custom kernels. This guide breaks down exactly what went wrong, who’s exposed, and the concrete steps to protect your infrastructure.

The Flaw: A Classic Off‑by‑One in Table Deletion

The SJA1105 family is a set of automotive‑grade switches supported under the kernel’s Distributed Switch Architecture (DSA) subsystem. The driver maintains an internal array of configuration entries; when a command deletes an entry from the middle or the end, the code has to shift the remaining elements to close the gap. The original implementation used memmove like this — in pseudo‑logic:

memmove(&table[i], &table[i+1], (size - i)  sizeof(entry))

Two distinct mistakes converge in that single call:

  1. Deleting the last element (i == size‑1): The source pointer &table[i+1] points one slot past the valid array. Even if the length argument computes to zero, constructing an out‑of‑range pointer is undefined behavior and triggers KASAN (Kernel Address Sanitizer) diagnostics on instrumented kernels.
  2. Deleting a middle element: The length calculation (size - i) is one element too large; the correct count of elements to shift after removal is size - i - 1. The buggy version over‑reads by one slot, again touching memory that doesn’t belong to the table.

The symptom that brought this to light was a KASAN out‑of‑bounds warning in the function sja1105tabledeleteentry, reported by syzbot fuzzing. KASAN is a dynamic memory safety tool that runs in testing kernels; it catches improper reads/writes that would otherwise silently corrupt data or crash the system later. In this case, the offending access often landed on an unmapped page, so the immediate consequence is a kernel oops and denial of service. While it’s theoretically possible for the out‑of‑bounds read to harvest adjacent memory — for instance, if the array sits next to sensitive slab objects — no public proof‑of‑concept has turned this into a reliable information leak, let alone remote code execution.

What the Patch Changes

The upstream fix, accepted into Linus Torvalds’ tree and backported to stable branches, does exactly two things:

  • Skips the memmove entirely when deleting the last element. There’s nothing to shift, so the copy is needless and the pointer construction alone was dangerous.
  • Corrects the element count for middle deletions, setting it to size - i - 1 so that the memmove never touches the invalid size index.

The change is intentionally minimal — a handful of lines in drivers/net/dsa/sja1105/sja1105staticconfig.c. By preserving existing semantics and avoiding a broader refactor, the fix carries very low regression risk and is straightforward for distribution maintainers to backport even to older kernel trees.

Affected Kernels and Hardware Scope

The vulnerability affects Linux kernels that include the SJA1105 driver. The driver was introduced in kernel 5.2, so any kernel from that version up to (but not including) the fixed stable points is theoretically vulnerable — until it receives a backported fix. Public advisory metadata and distribution trackers indicate the fixes are present in the 6.14 and 6.15 stable series, and they are being cherry‑picked into long‑term trees (e.g., 5.4, 5.10, 5.15, 6.1, 6.6) where applicable.

Crucially, exposure is hardware‑gated: you’re only vulnerable if your kernel has the driver compiled in (built‑in or as a module) and you actually use SJA1105‑based switch hardware. The typical footprint includes:

  • Network appliances (industrial routers, automotive gateways, managed Ethernet switches) that run a Linux‑based firmware with the SJA1105 driver.
  • Embedded system‑on‑chip (SoC) platforms that incorporate BroadR‑Reach PHYs or automotive‑grade switches.
  • Specialized cloud or virtual machine images that bundle a vendor‑supplied kernel with the driver enabled — some IoT‑focused OS images may do this.

General‑purpose desktop and server Linux installations (Fedora, Debian, Ubuntu) usually do not enable this driver by default. Even within WSL2, the default Microsoft‑supplied kernel (linux‑msft‑wsl) does not build the SJA1105 driver. However, if you or your team maintain custom kernels — for WSL, for development boxes, or for embedded Linux appliances that you manage from Windows — you should still check its configuration.

Vendor‑specific advisories have already been published:

  • Ubuntu classified the CVE as Medium priority in its USN notices and released fixed linux‑image packages.
  • Debian’s security tracker maps the flaw to specific package versions; unstable/forks branches already contain the patch.
  • SUSE and Amazon Linux have catalogued the CVE, with platform‑adjusted severity scores. Some long‑lived vendor kernels for older enterprise releases may show “No Fix Planned” — consult that vendor’s guidance.

Why Windows IT Admins Should Care

If your entire infrastructure runs on Windows Server and Hyper‑V, this CVE doesn’t touch you directly. But real‑world IT seldom stays that homogeneous. Many organizations use Linux‑based network appliances, industrial controllers, or SD‑WAN devices that run embedded Linux. Those devices often fall under the same IT management umbrella as Windows servers and endpoints, especially when they connect to Windows‑administered networks.

Additionally, any team that uses WSL2 with a self‑compiled kernel — for testing, CI/CD pipelines, or kernel‑level development — should verify whether the SJA1105 driver is enabled. An accidental exposure remains possible if a developer includes the driver while building a kernel for local debugging and then deploys that kernel across a fleet. The same logic applies to Linux VMs running on Hyper‑V or Azure that use custom kernels.

The practical risk profile is heavily weighted toward availability loss. The bug provokes a kernel oops, and while modern hardware and systemd can often recover from a panic via reboot, a crash on a network switch or critical router can take down a segment of your network. There’s also a low‑probability confidentiality risk: an out‑of‑bounds read could theoretically expose uninitialized kernel memory, potentially containing sensitive data (cryptographic keys, credentials). But again, no public exploit accomplishes a reliable leak.

How to Check Your Exposure and Harden Systems

Patching is the only foolproof solution, but you must first identify which machines need the update.

1. Inventory your Linux hosts

Run these commands on each Linux instance you manage:

echo "Kernel version: $(uname -r)"
lsmod | grep -i sja1105

or check module availability

test -f /lib/modules/$(uname -r)/kernel/drivers/net/dsa/sja1105.ko && echo "module found"

and kernel config (if /proc/config.gz exists)

zcat /proc/config.gz 2>/dev/null | grep -i SJA1105

If you see any CONFIGNETDSASJA1105=y or CONFIGNETDSA_SJA1105=m, the driver is present. If lsmod lists sja1105 as loaded, it’s actively in use.

For Windows workstations with WSL, open a WSL terminal (any distribution) and run the same checks. The default WSL kernel typically won’t have it, but if you’re using a custom kernel you manage from Windows, you need to verify.

2. Apply the right vendor patches

  • Ubuntu: Use the standard apt update && apt upgrade flow; fixed linux‑image packages are already in the repositories. Confirm the update’s changelog references CVE-2025-22107.
  • Debian: Follow the Debian Security Tracker to map CVE-2025-22107 to the fixed kernel package for your release (bullseye, bookworm, etc.).
  • SUSE, Amazon Linux, other enterprise distributions: Consume the vendor‑supplied kernel update via your usual patch management tool (zypper, yum, dnf). Reboot after installation.
  • Embedded appliances: Contact the device manufacturer. Many network appliance vendors roll kernel patches into firmware updates. If no patch is available, isolate the device or apply the mitigations below.

3. Mitigations if you cannot patch immediately

  • Unload or blacklist the module (modprobe -r sja1105) on hosts where the SJA1105 hardware is not actually in use. This will disable the driver entirely; make sure no critical network interface depends on it.
  • Restrict access to the DSA configuration path. Privileged processes usually manipulate these tables; ensure only trusted admins can reconfigure switch settings. If the device sits on a network, filter management interfaces to trusted subnets only.
  • Monitor kernel logs for any signs of trouble: journalctl -k | egrep -i 'sja1105|KASAN|out-of-bounds|oops'. Early detection of a crash can indicate that the bug is being triggered in your environment, giving you a trigger to expedite patching.

4. Verification after patching

After you’ve applied the kernel update and rebooted, double‑check that the new kernel is active (uname -r). If possible, run a functional test on any hardware that uses the SJA1105 driver to ensure configuration tables still work as expected. Watch kernel logs for a week in the pilot group for any new KASAN traces or regressions.

Outlook: A Low‑Risk Fix with a Long‑Tail Challenge

CVE-2025-22107 is not the kind of memory‑safety bug that leads to a global worm. It’s a tidy little off‑by‑one that, in practice, crashes the kernel when you delete a table entry in a specific automotive switch driver. The upstream fix is clean and safe; most Linux distributions have already shipped it. For Windows IT professionals who oversee a few Linux boxes or embedded devices, the actionable steps are straightforward: check exposure on those systems, install the vendor patch, and move on.

The bigger lesson is the long tail of embedded devices. Network appliances, industrial controllers, and IoT devices often run vintage kernels that never see an OTA update. Those devices will likely remain vulnerable for years unless the IT team actively tracks down firmware patches or applies compensating controls. While the risk of active exploitation is currently negligible, the stability impact alone — a sudden kernel panic on a critical switch — argues for timely remediation. Keep this CVE on your radar if your network includes any Linux‑based hardware that you don’t update as frequently as your servers. Automating the mapping between upstream commit IDs and vendor kernel packages will make future responses even faster.