CVE-2026-43410

What it actually does

This is a local denial-of-service flaw in the Linux kernel Stratix 10 Remote System Update (RSU) firmware driver. If RSU is disabled in the First Stage Boot Loader, the driver can free an SMC/HVC service channel after an async message setup failure but continue probing and register the svc_normal_to_secure_thread kernel thread. That thread later dereferences the invalid or NULL channel pointer, causing a kernel Oops/panic and system crash. The impact is availability loss only; the CVSS vector indicates local access with low complexity and low privileges, with no expected confidentiality or integrity impact.

Why it matters to the business

Systems running affected Linux kernels on Intel/Altera SoCFPGA Stratix 10 platforms can crash if this driver path is reached while RSU is disabled in firmware. For organizations using these devices in embedded, industrial, telecom, edge, or appliance deployments, the practical consequence is unexpected reboot or outage of the affected device, potentially interrupting production workloads or field operations. The vulnerability is not listed in CISA KEV, has very low EPSS, and has no known public exploit maturity in the provided data, so urgency is highest for organizations that operate Stratix 10 systems with RSU disabled rather than for broad Internet-exploitation risk.

How an attack unfolds

An attacker must already have local access with sufficient privileges to influence kernel driver initialization, module loading, device configuration, or reboot behavior on an affected Stratix 10 system. The vulnerable condition occurs when the platform firmware has RSU disabled, causing rsu_send_async_msg() to fail during probe. Instead of stopping safely, the vulnerable driver frees the service channel and continues execution. Once svc_normal_to_secure_thread runs, it accesses the invalid channel and triggers a NULL pointer dereference in kernel context, leading to a kernel panic. In realistic scenarios, exploitation is most likely a local availability attack or an accidental outage caused by a vulnerable kernel/firmware configuration mismatch, not remote compromise.

How to fix it

Upgrade to a Linux kernel version that includes the upstream fix for the stratix10-rsu driver, or apply the vendor/backport patch that makes the probe path clean up the async client and return early when rsu_send_async_msg() fails. If a packaged kernel is used, install the fixed kernel provided by the distribution, board vendor, or device manufacturer and reboot into that kernel. Where immediate patching is not possible, reduce exposure by disabling or preventing loading of the stratix10-rsu driver on systems that do not require RSU functionality, or enable/configure RSU consistently in FSBL/firmware where operationally appropriate. Because this is a kernel availability issue, live mitigation should be validated carefully on representative hardware before production rollout.

How to confirm the fix worked

Confirm the running kernel contains the corrected stratix10-rsu logic from the vendor or upstream patch set. Verify the system is booted into the updated kernel, not merely that the package is installed. On Stratix 10 hardware, test the RSU-disabled firmware configuration in a controlled environment and confirm driver probe exits cleanly without registering a thread that later crashes. Review dmesg or persistent kernel logs after boot for absence of NULL pointer dereference, kernel Oops, or panic messages involving svc_normal_to_secure_thread, stratix10_svc_free_channel(), rsu_send_async_msg(), or stratix10-rsu. If the driver is not required and has been disabled, confirm it is not loaded and no matching module appears in lsmod, sysfs, or boot logs.

Typical attack path

1. Identify a Linux system running on Intel/Altera SoCFPGA Stratix 10 hardware with the vulnerable stratix10-rsu firmware driver present.
2. Confirm or create the precondition where Remote System Update is disabled in the First Stage Boot Loader or firmware configuration.
3. Trigger driver probe, module loading, or a reboot path that initializes the Stratix 10 RSU service logic.
4. Cause rsu_send_async_msg() to fail, leading the driver to free the channel while incorrectly continuing probe execution.
5. Wait for svc_normal_to_secure_thread to execute and dereference the invalid channel pointer.
6. System experiences a kernel Oops or panic, resulting in denial of service until reboot or recovery.

How to detect it

To determine whether this issue has already occurred, review kernel logs, serial console captures, crash dumps, pstore/ramoops records, journald, syslog, and device management logs for kernel panic or Oops events matching the reported NULL pointer dereference. Key artifacts include references to svc_normal_to_secure_thread, rsu_send_async_msg(), stratix10_svc_free_channel(), stratix10-rsu, svc_smc_hvc_thr, and NULL pointer dereference at virtual address 0000000000000008. On embedded devices, persistent logging may be limited, so collect bootloader logs, watchdog reset reasons, kernel crash dumps, and remote management telemetry showing unexpected reboot loops or panic resets. There are no network IOCs expected because exploitation is local and results in a kernel crash rather than command execution or beaconing.

• Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008
• Internal error: Oops: 0000000096000004
• svc_normal_to_secure_thread+0x38c/0x990
• svc_normal_to_secure_thread
• rsu_send_async_msg
• stratix10_svc_free_channel
• stratix10-rsu
• Comm: svc_smc_hvc_thr
• Hardware name: SoCFPGA Stratix 10 SoCDK
• [0000000000000008] user address but active_mm is swapper
• Call trace: svc_normal_to_secure_thread
• kthread+0x150/0x210
• ret_from_fork+0x10/0x20

What your security team should do

• Inventory Linux systems running on Intel/Altera SoCFPGA Stratix 10 platforms and determine whether the stratix10-rsu driver is present or enabled.
• Prioritize remediation for production embedded, industrial, edge, or appliance deployments where an unplanned reboot would cause operational disruption.
• Obtain the corrected kernel from the Linux distribution, board vendor, or device manufacturer; where no fixed package is available, evaluate a controlled backport of the upstream fix.
• Reboot systems into the fixed kernel and verify the running kernel version/build, since kernel package installation alone does not remediate exposure.
• For systems that do not use Remote System Update, consider disabling the stratix10-rsu driver as a compensating control until patching is complete.
• Monitor kernel logs for Oops or panic events involving svc_normal_to_secure_thread and Stratix 10 RSU components to identify prior crashes or attempted triggering.
• Treat this as a local availability risk rather than a remote code execution issue; focus response on uptime, kernel lifecycle management, and hardware/firmware configuration consistency.