Linux Stratix10 SVC Driver Patch Fixes Kernel Panics (CVE-2025-68328)

A recently assigned CVE — CVE-2025-68328 — pins down a subtle but consequential bug in the Linux kernel’s Stratix10 Service Layer driver (stratix10-svc) that could cause module removal to fail and trigger a kernel panic, and kernel developers have issued a corrective patch to eliminate the erroneous use of driver-data helpers that led to the problem. The patch addresses incorrect use of platform_set_drvdata and dev_set_drvdata (they were being used inconsistently for the same underlying data), which allowed one driver-data store to overwrite the other and ultimately caused rmmod to fail, producing panics during kthread_stop and FIFO cleanup. The issue is categorized as a local, availability-impacting flaw and has been fixed in the upstream kernel trees and carried into stable branches; Linux distributions have begun classifying and packaging the fix for affected kernel packages.

Background​

What is stratix10-svc and why it matters​

The stratix10-svc driver implements the Service Layer (SVC) support for Intel Stratix 10 SoC devices. On Stratix 10 systems (SoC-FPGA platforms), the SVC driver orchestrates communication between kernel-space clients (for example, the FPGA manager and the remote system update — RSU — service) and privileged firmware or secure-monitor code that runs at a higher exception level. The driver manages:

• Shared memory pools used to pass configuration data and buffers to secure firmware,
• Per-controller FIFOs for message passing,
• Kernel threads used to drive secure monitor calls (SMC/HVC) and wait for responses,
• Genpool-based memory allocations and registration of service clients.

Because the SVC driver exists at the intersection of kernel device infrastructure and platform-specific secure services, a defect in its lifecycle management (probe/remove) can have outsized consequences for system stability and device availability.

How this bug was discovered and fixed​

Kernel maintainers and developer threads show the defect was corrected by a compact patch that standardizes the usage of driver-data APIs. The offending behavior — using both platform_set_drvdata and dev_set_drvdata in ways that stored the same pointer into device structures — allowed one assignment to silently overwrite another. When the module was removed (rmmod), the remove path relied on retrieving per-controller data from the device structures; with the overwrites in place, the remove sequence could attempt to free or stop resources using corrupted pointers. That, in turn, could cause a kernel panic while invoking kthread_stop on the controller task or while freeing the controller’s FIFO.
The upstream change was committed to the stable kernel trees and to release branches intended to carry fixes into distribution kernels. Several Linux distribution security trackers now mark the issue as resolved in package updates once maintainers apply the corrected driver code.

---

Technical analysis: root cause and mechanics​

The driver-data helpers: platform_set_drvdata vs dev_set_drvdata​

In the Linux driver model there are two commonly used helpers for associating driver-private pointers with kernel device objects:

• dev_set_drvdata(struct device dev, void data) — sets the driver data pointer on a generic device structure.
• platform_set_drvdata(struct platform_device pdev, void data) — a thin wrapper that calls dev_set_drvdata(&pdev->dev, data).

Both functions set a pointer in the same underlying field (the device’s driver_data). Using them is routine in platform drivers: the driver typically stores its per-device private data in the probe callback using platform_set_drvdata, and retrieves it in remove using platform_get_drvdata.

What went wrong in stratix10-svc​

The Stratix10 SVC driver’s probe/remove sequence deals with two related objects: the global SVC device (svc) and one or more per-controller objects (controller). The buggy code used the device/ platform driver-data helpers inconsistently — setting driver-data for both objects in a way that they ended up colliding (i.e., storing the same pointer slot). Concretely, one part of the probe stored a pointer using the raw device helper while another stored a pointer using the platform helper intended for the platform device; because they target the same field, the latter write could overwrite the earlier one.
This collision means that during module removal the code could retrieve an incorrect pointer for the controller and then perform cleanup operations (kthread_stop, kfifo_free, gen_pool_destroy, list_del) on invalid or already-freed memory. These cleanup steps are sensitive; passing corrupted data to kthread_stop or freeing an already-initialized FIFO can provoke kernel panics or memory corruption, making the failure mode effectively a denial-of-service for the affected kernel.

Improved semantics in the fix​

The upstream patch corrects the inconsistent uses so that each device’s driver-data store is used in a consistent and non-conflicting way — either consolidating into a single, clearly owned driver-data pointer per device structure or using dedicated container objects and proper retrieval; the net effect is that remove paths can reliably obtain the correct controller object and perform safe cleanup.

---

Scope: which systems are affected​

Kernel versions and modules​

The Stratix10 SVC driver has been present in the Linux kernel for multiple releases, typically built when the configuration option CONFIG_INTEL_STRATIX10_SERVICE (or similar platform-specific flags) is enabled. The module name is commonly stratix10-svc. Historically the driver appears in stable and long-term kernel series including the 5.x and 6.x trees where Stratix 10 support is maintained for SoC FPGA platforms.
The patch was explicitly targeted at stable series and release branches (for example, submit notices and stable kernel pull requests indicate fixes for v6.18-forward and backported stable branches). Distributions that ship kernels compiled with Stratix 10 support or maintain vendor-specific SoC kernels are the principal places where this defect would be present.

Affected environments​

• Embedded or server-class systems using Intel Stratix 10 SoC FPGAs where the SVC driver is built and loaded.
• Systems where the kernel is configured to include CONFIG_INTEL_STRATIX10_SERVICE or where a vendor kernel includes the stratix10-svc module.
• Virtualized or otherwise specialized images are affected only if they are running kernels and hardware that expose the Stratix10 SVC device tree nodes.

Systems that do not include stratix10-svc (i.e., generic desktop or server kernels without FPGA SoC support) are not affected.

---

Impact and risk assessment​

Nature of the risk​

This bug is primarily an availability issue. The erroneous driver-data writes can result in:

• rmmod failure — attempts to remove the module may fail unpredictably.
• kernel panic — if remove attempts trigger kthread_stop on a corrupted pointer or free kernel FIFOs with bad state, a panic may occur.
• denial-of-service — a locally-triggerable kernel panic effectively halts affected systems until reboot.

Notably, the bug does not appear to expose confidential data nor to provide remote code execution. The vulnerability requires local access to the system (or at least the ability to cause driver lifecycle events) and low privileges per distribution assessments. Because it is an availability-only flaw, the primary real-world risk is operational disruption rather than data exfiltration.

Privileges and attack surface​

Distribution assessments classify the issue as local with low privileges required. In practice, the operations that trigger the flaw are kernel module lifecycle events and device interactions managed by the kernel — these generally require root privileges to manipulate (e.g., rmmod), but other local kernel paths that cause the driver to probe or remove could be possible depending on system configuration and device topology. In embedded systems where service management or automated updates control modules and device nodes, triggering the flawed code path may be simpler.

Exploitability and prevalence​

At the time of disclosure and subsequent fixes there are no widespread reports of exploit code targeting this specific defect. Security trackers show a low probability of exploitation and rate the overall severity as moderate because of the localized nature of the bug. However, availability bugs can be weaponized in complex environments: an attacker with local access can intentionally cause instability or trigger reconfiguration flows to provoke removals and panics.
It is important to emphasize that distribution and vendor assessments differ in scoring methodology; some vendors rate the issue as CVSS 3.x mid-range (moderate) with high availability impact but no confidentiality leak. Organizations should evaluate risk based on whether Stratix 10 hardware and the SVC driver are present in their fleets.

---

Detection: how to find if you’re affected​

• Check whether the kernel has the module loaded:
• Run: lsmod | grep stratix10_svc (module may show as stratix10-svc or stratix10_svc depending on build).
• Inspect kernel configuration:
• For running kernels with config exposed: zcat /proc/config.gz | grep -i STRATIX10 or check /boot/config-$(uname -r) for CONFIG_INTEL_STRATIX10_SERVICE or similar entries.
• Look for device tree nodes:
• Search the device tree for intel,stratix10-svc or intel,agilex-svc entries; presence suggests the driver may be active on boot.
• Review kernel logs for symptoms:
• Examine dmesg or journal logs for messages involving SVC, FIFOs, kthread_stop failures, or panic call traces referencing svc, fifo, or kthread. Unexplained crashes during module removal are a red flag.
• Distribution security trackers:
• Check your vendor/distribution kernel advisory lists or package changelogs to see whether the kernel package for your release contains the patch.

---

Remediation and mitigation​

Primary remediation: apply kernel updates​

The definitive fix is to apply the upstream patch integrated into kernel maintenance branches. Steps:

• Apply a kernel update from your distribution that includes the corrected driver code (preferred).
• If using vendor or custom kernels, merge the upstream fix (the compact driver-data correction) into your kernel source and rebuild the kernel or module.
• For long-term support (LTS) kernels that your distribution maintains, verify the vendor release notes to ensure the fix is included before rolling to production.

Because the fix is a small, targeted change to the driver’s probe/remove behavior, most vendors have or can apply the patch without broader functional changes. Distributions typically mark the update as moderate priority for images that include Stratix 10 support.

Workarounds and short-term mitigations​

• Avoid rmmod on affected systems — do not remove the stratix10-svc module on production systems until they are updated. If the module must be removed, prefer a controlled reboot to avoid unpredictable crash paths.
• Disable the driver at boot — if Stratix 10 hardware is present but not in active use, consider blacklisting the module or disabling the driver via kernel boot parameters until an update is available. This prevents the probe sequence from instantiating the problematic state.
• Minimize local user access — limit local access to systems with Stratix 10 platform support to reduce the chance a low-privileged user can trigger a module lifecycle action.
• Test updates in a lab — given the kernel’s role, test the vendor-supplied kernel update in a controlled environment before wide deployment.

Safe update sequence for sysadmins (recommended)​

• Identify machines with Stratix10 SVC present (lsmod, device tree, kernel config).
• Schedule maintenance windows for those machines.
• Install vendor/distribution kernel updates that include the driver fix.
• Reboot machines (kernel module changes normally require a reboot).
• Verify post-update logs: dmesg for clean probe and remove messages and absence of SVC-related panic traces.
• If a reboot is not possible, consider hotpatching policy only if your environment supports reliable live kernel patching and the vendor supplies such a hotpatch — otherwise plan a reboot.

---

What administrators and developers should watch for​

• Patch availability — track distribution advisories for the specific kernel package you run. The patch is included in upstream stable branches and should appear in distro kernels that ship Stratix 10 support.
• Testing of cleanup paths — developers maintaining SoC kernels should explicitly test probe/remove and kthread_stop flows in the stratix10-svc driver to ensure robust lifecycle handling.
• Device lifecycle automation — automated processes that load/unload kernel modules during updates or reconfiguration should be reviewed to avoid inducing unwanted rmmod events on affected systems before they are patched.
• Monitoring for reoccurrence — after patching, monitor logs for any related messages and ensure there are no regressions introduced by backports.

---

Critical evaluation and takeaways​

Strengths of the response​

• The upstream fix is narrowly scoped and addresses the root cause (inconsistent driver-data writes) with minimal footprint.
• Kernel maintainers quickly landed the patch into relevant trees, enabling distributions to cherry-pick and deliver updates.
• The bug is not remotely exploitable for data theft or code execution; its primary impact is availability, simplifying prioritization in some environments.

Risks and residual concerns​

• Local availability exploits are still operationally serious in embedded and control-plane environments where reboots are costly or disruptive.
• Not all distributions or vendor kernels will push the fix at the same cadence; embedded device vendors or long-term-support images may lag, prolonging exposure.
• Systems with automated device reconfiguration or hot-swap workflows may unintentionally trigger the buggy removal path, especially in manufacturing or test environments where modules are frequently probed and removed.

Final assessment​

CVE-2025-68328 is an instructive example of how small API misuses in kernel drivers can create significant system stability issues. The fix is straightforward and already upstreamed, but the practical risk is governed by the presence of Stratix 10 hardware and whether a system’s kernel configuration includes the service layer driver. For administrators and embedded developers, the correct course is prompt patching in affected kernels, cautious management of module unloads, and verifying device lifecycle behaviors in test labs before rolling updates into production fleets.

---

Action checklist​

• Identify affected hosts by searching for the stratix10-svc module and the CONFIG_INTEL_STRATIX10_SERVICE kernel config.
• Review vendor or distribution security advisories and install kernel updates that include the stratix10-svc fix.
• If an immediate kernel update is not available, blacklist the module or avoid rmmod operations until a patch can be applied.
• Test patched kernels to confirm SVC probe/remove sequences behave correctly and that no new regressions were introduced.
• Continue monitoring vendor advisories and kernel trees for any further follow-ups to the original fix.

---

The stratix10-svc correction removes an unnecessary source of instability for Stratix 10 platforms and is a reminder that even low-level helper wrappers must be used consistently. Applying the available kernel fixes and following the mitigation steps above will neutralize the immediate availability risk posed by this code path.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center