The Linux kernel received a targeted fix for an out‑of‑bounds memory access in the SJA1105 driver that surfaced as a KASAN warning in sja1105_table_delete_entry, tracked as CVE‑2025‑22107; upstream maintainers corrected the logic that drove an unsafe memmove so the driver no longer touches memory past the array end.
Background
The SJA1105 family is a set of BroadR‑Reach/Automotive switches supported in the Linux kernel under the DSA (Distributed Switch Architecture) subsystem. The driver implements tables that hold switch configuration entries and occasionally removes entries in the middle or at the end of an array. A subtle off‑by‑one condition in the code that shifts array elements during deletion caused the code to access an element just past the last valid entry, which in some configurations triggered a KASAN (KernelAddressSANitizer) out‑of‑bounds warning. KASAN is a dynamic memory safety tool used by kernel developers and fuzzers (notably syzbot) to detect invalid memory accesses at runtime. KASAN warnings typically expose reads or writes that touch unmapped pages or freed memory; even when the offending access does not immediately corrupt state, the presence of an out‑of‑bounds access is a real stability and security concern because it can lead to crashes or information disclosure on certain memory layouts. Practical incident post‑mortems from other KASAN‑reported fixes show that the immediate symptom is often denial‑of‑service (kernel oops/panic) rather than a direct, reliable remote code‑execution primitive — but the kernel‑level context makes any memory‑safety bug worth prompt remediation.
What the fix changed (overview)
At a high level the fix for CVE‑2025‑22107 does two things:
- Removes unnecessary memmove when deleting the last element in the table; copying the range [i + 1, end) is needless when i points at the final element.
- Corrects the memmove length calculation to move exactly size − i − 1 elements when deleting a middle element, avoiding touching the out‑of‑bounds element at index size (which does not exist).
The public advisories and vulnerability records describe the error succinctly: the existing memmove touched element i + 1 when i was already the last index, and even when deleting non‑terminal elements the byte count passed to memmove was too large by one element. The net effect was that the code
touched an out‑of‑range element; depending on whether that memory mapped to a valid page this could cause a KASAN report or a page fault. The upstream remedy is intentionally minimal and safe: adjust the bounds and skip the copy for the trivial last‑element case. That approach preserves existing semantics while eliminating the out‑of‑bounds access and making the routine robust to malformed state or edge case indexes.
Technical deep dive: why the bug happened
The vulnerable code implements an array‑backed table and removes a single element at index i by shifting the subsequent elements left by one slot. In pseudo‑logic the original code did something like:
- If deleting element at index i:
- memmove(&table, &table[i + 1], (size - i) sizeof(entry);
There are two mistakes in that approach:
- When i equals size − 1 (the last element), the source pointer &table[i + 1] points one element past the array and is out of bounds. Even if memmove is invoked with a zero byte length in some compilers or platforms, constructing the source pointer itself can trigger KASAN diagnostics or undefined behavior.
- The length parameter was calculated as (size − i) rather than (size − i − 1). The correct number of elements to shift after removing index i is the count of elements after i, which is size − i − 1.
Because the buggy code referenced the out‑of‑range element, the function could trip KASAN if that memory was not mapped or had been freed; in practice the failure manifested as a KASAN out‑of‑bounds warning rather than as a classic read‑use or write‑use in active structure fields. That nuance is important: the patched code does not change how the table is used after deletion — it simply avoids ever touching memory outside the legitimate array bounds.
Affected scope: kernel ranges, distributions, and product impact
Multiple vulnerability databases and distribution trackers list affected kernel versions and package mappings. The collective picture is:
- Upstream git ranges and advisory metadata indicate affected kernels from 5.2 up to but excluding several fixed stable points; distribution trackers point to fixed package builds in the 6.14/6.15 stable trees or later. In short: kernels in the 5.x and early 6.x ranges may be vulnerable until backported fixes are applied.
- Debian’s tracker maps a number of packaged kernels as vulnerable and shows fixed versions landing in later unstable/forky branches — administrators should consult their distribution’s security tracker to see exact package versions for their release.
- Ubuntu published advisories that include this CVE and assign a Medium priority in their USN notices; fixed linux‑image packages are included in the various Ubuntu updates and meta advisories.
- Enterprise vendors and cloud OS vendors (SUSE, Amazon, SUSE security pages and Amazon ALAS) have cataloged the CVE with platform‑specific severity and status information; some vendor kernels that are long‑lived or deliberately conservative about backports may be marked “No Fix Planned” for older kernel branches (operators should validate per vendor guidance).
Because SJA1105 is part of the in‑kernel DSA driver set, the realistic exposure only applies to systems that have the driver compiled in (either built into the kernel or as a module) and that create or manipulate SJA1105 tables at runtime. That means:
- Network appliances, SoC platform images, or embedded devices using SJA1105 hardware drivers are the most likely to see the code path exercised.
- General desktop or server images that do not include SJA1105 support are not directly exposed.
- Virtual machine images or host kernels that include SJA1105 in vendor kernels (for example, specialized embedded/cloud kernels) should be validated against vendor advisories.
Exploitability and realistic risk model
From the published materials and vendor summaries the security implications break down like this:
- Primary impact: availability — KASAN warnings typically indicate out‑of‑bounds accesses that can cause kernel oops/panic and disrupt service. Public records emphasize crashes and instability as the main outcome, not a trivial remote code execution (RCE) path.
- Confidentiality risk: low but non‑zero — out‑of‑bounds reads can leak adjacent kernel memory under the right allocator/layout conditions. The specific SJA1105 bug appears to touch but not reuse the out‑of‑bounds element; however, touching unmapped or unexpected pages could surface sensitive bytes into logs or crash dumps.
- Privilege and attack vector: local or local‑adjacent (AV:L). An attacker must have the ability to cause the kernel to run the SJA1105 table deletion path — typically through local access or by interacting with device management code that manipulates the tables. In many realistic deployments that capability is limited to privileged processes or device management stacks.
- RCE likelihood: considered low based on available public analysis; there is no authoritative public proof‑of‑concept that converts this specific out‑of‑bounds touch into an exploit achieving arbitrary code execution or privilege escalation. Treat any claims of immediate RCE as uncorroborated unless reproducible exploit artifacts are published.
Patching, verification, and rollout guidance
- Inventory: Determine whether your kernels include SJA1105 and whether your host kernels fall inside the affected ranges.
- Check kernel version: uname -r.
- Check whether the driver is present: lsmod | grep sja1105 or inspect the kernel config (zcat /proc/config.gz | grep SJA1105 or grep -i sja1105 /boot/config-$(uname -r).
- For distributions, consult the distro security tracker and package changelogs to map CVE‑2025‑22107 to the fixed kernel package for your release.
- Patch: Install vendor/distribution kernel updates that include the upstream fix.
- Use the vendor advisory or your package manager to identify the fixed linux‑image/kernel package version. Reboots are required for kernel fixes to take effect.
- Verify the package changelog or advisory lists the upstream commit ID or CVE number before mass rollout. Distribution trackers (Debian, Ubuntu, SUSE, Amazon) publish package mapping and status.
- Test: Apply patches to a pilot ring first.
- Validate functionality that uses the SJA1105 hardware or DSA tables.
- Monitor kernel logs (journalctl -k, dmesg) for residual KASAN traces or regressions for at least 7–14 days post‑patch in the staging ring.
- Rollout: Expand patches in waves and maintain rollback plans.
- Coordinate reboots with application owners, particularly for network appliances or embedded fleets.
- If you cannot patch immediately:
- Consider unloading or blacklisting the module (modprobe -r sja1105) on hosts where the SJA1105 device is not required; beware that doing so disables the hardware driver and affects network functionality.
- Isolate systems that may process untrusted inputs which could exercise the SJA1105 table code path.
- Restrict who can manipulate DSA device configuration and avoid automated scripts that reconfigure SJA1105 tables from untrusted inputs or containers.
- Verification commands and hunting pointers:
- Search kernel logs for KASAN or oops traces mentioning sja1105_table_delete_entry or sja1105: journalctl -k | egrep -i 'sja1105|KASAN|out-of-bounds|oops'
- For custom kernels: inspect drivers/net/dsa/sja1105/sja1105_static_config.c for the patched memmove logic and confirm the fix commit exists in your tree. Public advisories reference stable commits and upstream patches for cross‑checking.
Why the chosen fix is sensible — and what remains
Strengths of the fix
- Minimal and focused: the remedy changes only the deletion routine’s bounds-checking and avoids a broad rewrite, which reduces regression risk and simplifies backporting into stable vendor kernels.
- Defensive: by avoiding construction of an out‑of‑range pointer and ensuring the memmove length is correct, the patch eliminates the direct cause of the KASAN warning and the potential for touching unmapped memory.
Residual risks and the long tail
- Vendor backport variability: embedded and vendor‑supplied kernels often lag upstream; appliances and SoC images may remain vulnerable longer than mainstream distribution kernels. Operators must query vendors for patch status or apply compensating controls.
- Edge cases in exploitation: while the public record frames this as an availability/stability bug, sophisticated attackers sometimes combine multiple primitives. Although there is no public PoC for RCE, defenders should not dismiss the hazard in multi‑tenant or hostile environments.
Practical detection examples and safe triage steps
- Quick inventory:
- uname -r
- lsmod | grep sja1105 (or check /lib/modules/$(uname -r)/kernel/drivers/net/dsa)
- zcat /proc/config.gz | grep -i SJA1105
- Hunting for KASAN/OOPS evidence:
- journalctl -k --no‑pager | egrep -i 'KASAN|sja1105|out-of-bounds|BUG:'
- Check crash dumps or kdump archived vmcore files for traces referencing sja1105_table_delete_entry.
- Safe forensic capture:
- If you see a KASAN trace, collect and centralize dmesg/journalctl output and preserve kernel crash dumps (kdump/vmcore) before reboot. Kernel oopses often wipe transient logs.
- Avoid running reproducer code in production. If you must validate behavior, use a KASAN‑enabled test kernel and isolated hardware in a lab environment. Public reproductions often rely on instrumented kernels and fuzzers — do not run those on production appliances.
Cross‑checks and verification notes
Multiple independent tracking services corroborate the same root cause and remediation:
- The OSV entry and the NVD/Ubuntu/DEBIAN trackers summarize the bug and list upstream commit references for the stable trees. These public advisories supply the authoritative mapping between CVE and upstream commit(s).
- OpenCVE / CVE‑detail aggregators and vendor trackers (Ubuntu, SUSE, Amazon ALAS) provide package‑level guidance and reported CVSS scores; CVSS scorings vary slightly across vendors, which is common because vendors apply contextual impact weighting. Administrators should prioritize by exposure rather than a single numeric score.
Caveat on direct upstream commit access: some advisory records include direct links to upstream stable commits on git.kernel.org; in practice, automated tooling or network access policies may block direct retrieval in constrained environments. Where direct upstream access is unavailable, rely on the distro’s package changelog that lists the included upstream commits or the vendor advisory that maps the CVE to a package build. If you maintain your own kernel builds, inspect your local git history for the upstream commit IDs referenced by distro advisories to confirm the fix is present.
Priorities and recommended timeline
- Immediate (days): Identify hosts with SJA1105 driver present and schedule patching for any systems that expose the driver or are in production network roles.
- Short term (1–2 weeks): Apply vendor kernel updates to pilot and then production hosts. For embedded appliances or vendor‑supplied images, request vendor status and timelines; if no vendor update is available, plan compensating isolation or hardware replacement where business critical.
- Medium term (1–3 months): Validate that all fleet images and embedded systems have been reconciled (either patched or mitigated). Add the CVE to configuration management inventories so future audits capture remediation state.
- Ongoing: Maintain KASAN/test lanes for catching regression and memory‑safety issues and automate mapping between upstream commit IDs and packaged kernel builds to accelerate verification in the future.
Conclusion
CVE‑2025‑22107 is a classic, fix‑small‑and‑ship‑quick memory‑safety correction: a memmove in the SJA1105 DSA driver touched one element too far and could create a KASAN out‑of‑bounds warning and potential kernel instability. The upstream remedy is minimal, safe to backport, and eliminates the out‑of‑bounds access by skipping unnecessary copies and fixing the shifted element count. Operators should treat this as a targeted kernel patch: verify whether the SJA1105 driver exists in your kernels, apply vendor or distribution kernel updates that include the upstream fix, and schedule reboots after test validation. For long‑tail embedded and vendor images, confirm vendor timelines and apply mitigations (module blacklists, isolation) until patches are available. Public advisories and vulnerability trackers provide package mappings and upstream commit references; cross‑check your distribution’s changelogs to confirm the fix is present before mass rollout.
Source: MSRC
Security Update Guide - Microsoft Security Response Center*