CVE-2026-43410: Linux Kernel Privilege Escalation Flaw

CVE-2026-43410 Overview

CVE-2026-43410 is a NULL pointer dereference vulnerability in the Linux kernel's stratix10-rsu firmware driver. The flaw triggers a kernel panic on Intel Stratix 10 SoC FPGA platforms when Remote System Update (RSU) is not enabled in the First Stage Boot Loader (FSBL). When rsu_send_async_msg() fails, the driver frees the service channel via stratix10_svc_free_channel(), but the probe function continues and registers svc_normal_to_secure_thread(). The kthread then dereferences the freed channel, producing an Oops at virtual address 0000000000000008 and halting the system.

Critical Impact

Local denial of service through kernel panic on affected SoCFPGA Stratix 10 hardware where RSU is disabled in firmware.

Affected Products

• Linux kernel (mainline) containing the firmware/stratix10-rsu driver
• Intel SoCFPGA Stratix 10 platforms with RSU disabled in FSBL
• Kernel builds prior to commits aa5739e0c51a and c45f72631000

Discovery Timeline

• 2026-05-08 - CVE-2026-43410 published to NVD
• 2026-05-12 - Last updated in NVD database

Technical Details for CVE-2026-43410

Vulnerability Analysis

The stratix10-rsu driver provides the kernel-side interface to the Remote System Update service exposed by the Stratix 10 Secure Monitor Call (SMC) firmware. During probe, the driver invokes rsu_send_async_msg() to initialize state with firmware. When RSU is not enabled in the FSBL, this asynchronous message fails and the driver releases the service channel through stratix10_svc_free_channel(). Probe execution does not abort on this failure. It continues and registers the svc_normal_to_secure_thread() kthread against the now-freed channel.

Once scheduled, the kthread accesses channel pointer state and dereferences a NULL field at offset 0x8, producing the kernel Oops captured in the report (pc : svc_normal_to_secure_thread+0x38c/0x990). Because active_mm is swapper at the time of the fault, the panic occurs in kernel context and is unrecoverable, classifying the issue as a kernel-mode NULL pointer dereference [CWE-476] leading to denial of service.

Root Cause

The root cause is missing error-path cleanup in the driver probe. When rsu_send_async_msg() returns failure, the async client is left registered and probe continues to install svc_normal_to_secure_thread(). The thread later operates on the channel that was already released, yielding a stale, partially-NULL structure.

Attack Vector

The condition is reached locally through firmware configuration, not through a network or unprivileged user input path. Any boot of an affected kernel on a Stratix 10 board where RSU is disabled in the FSBL triggers the panic. There is no indication of remote exploitation, and EPSS is 0.025%.

No verified exploit code is available. See the upstream commits aa5739e0c51a and c45f72631000 for the corrected probe and cleanup logic.

Detection Methods for CVE-2026-43410

Indicators of Compromise

• Kernel Oops referencing svc_normal_to_secure_thread+0x38c/0x990 in dmesg or serial console output.
• Panic message: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008.
• Process context Comm: svc_smc_hvc_thr at the time of fault on SoCFPGA Stratix 10 hardware.

Detection Strategies

• Inventory running kernel versions on Stratix 10 SoCDK and derivative boards and compare against patched stable branches containing commits aa5739e0c51a or c45f72631000.
• Audit FSBL configuration to identify boards where RSU is disabled, since these are the systems that trigger the fault.
• Parse boot logs collected by your fleet management or telemetry pipeline for the specific Oops signature above.

Monitoring Recommendations

• Forward kern.crit and serial console output from embedded Stratix 10 systems to a central log store and alert on Internal error: Oops events.
• Track unexpected reboots of FPGA-based appliances, which are the most likely visible symptom of this kernel panic.

How to Mitigate CVE-2026-43410

Immediate Actions Required

• Update the Linux kernel on affected Stratix 10 systems to a version including commits aa5739e0c51a and c45f72631000.
• For boards where the kernel cannot be updated immediately, enable RSU in the FSBL so the failing code path is not taken.
• Validate boot stability after the change by checking dmesg for any residual stratix10-rsu errors.

Patch Information

The upstream fix correctly cleans up the async client and returns early when rsu_send_async_msg() fails, preventing svc_normal_to_secure_thread() from being registered against an invalid channel. The fix is available in the following commits: Kernel Git Commit aa5739e0 and Kernel Git Commit c45f7263.

Workarounds

• Enable Remote System Update in the First Stage Boot Loader configuration so the driver's async initialization succeeds.
• Blacklist the stratix10-rsu module on systems that do not require RSU functionality, preventing the probe path from executing.

# Configuration example: prevent stratix10-rsu from loading until patched
echo "blacklist stratix10-rsu" | sudo tee /etc/modprobe.d/blacklist-stratix10-rsu.conf
sudo update-initramfs -u
sudo reboot