CVE-2026-53204

What it actually does

This flaw is a Linux kernel NULL pointer dereference in the Intel/Altera Stratix 10 Remote System Update firmware driver. During driver probe, if an RSU service message times out while an SMC call is still pending, the error path frees the service channel and clears the channel service-client pointer, but execution can continue and queue another request on the same invalidated channel. When the service thread later processes the callback path, it dereferences the cleared pointer, causing a kernel oops or panic. The practical impact is denial of service on systems using the affected Stratix 10 RSU firmware path; it is not currently known to provide code execution or privilege escalation.

Why it matters to the business

Organizations running Linux on affected Stratix 10 platforms could experience unexpected kernel crashes during device initialization or firmware/RSU-related operations, potentially causing service interruption for embedded, industrial, telecom, or edge systems that rely on those devices. The public exploitation likelihood appears low at this time: EPSS is 0.00107, there is no known exploit maturity, and it is not listed in CISA KEV or associated with ransomware campaigns. However, kernel crashes on specialized infrastructure can still create operational downtime and may require physical or out-of-band recovery depending on the deployment.

How an attack unfolds

An attacker would need a path to influence the affected Stratix 10 RSU driver probe sequence or the underlying firmware service behavior so that rsu_send_msg() times out while the secure monitor call is still pending. After the timeout, vulnerable probe error handling frees the service channel but does not immediately stop all subsequent operations. The driver then attempts to send another RSU command using the same channel whose service-client pointer has already been cleared. When the asynchronous service kthread later invokes the receive callback, it dereferences the NULL pointer and triggers a kernel fault. In realistic scenarios, exploitation is most plausible by a local actor with the ability to repeatedly load, bind, unbind, or otherwise trigger the driver on affected Stratix 10 hardware, or by fault conditions in the firmware/service layer that cause repeated timeouts. There is no public indication that this vulnerability is being exploited in the wild.

How to fix it

Apply a Linux kernel version or vendor kernel update that includes the fix for the Stratix 10 RSU driver probe error paths. The corrected behavior removes the async client, frees the channel, and returns immediately after rsu_send_msg() or rsu_send_async_msg() failures instead of queuing further messages on a freed channel. If an immediate kernel update is not possible, reduce exposure by disabling or blacklisting the stratix10-rsu driver where RSU functionality is not required, restricting local administrative access, preventing untrusted users from loading or binding kernel modules, and avoiding unnecessary RSU firmware operations until patched. For appliance or embedded deployments, obtain fixed firmware/kernel images from the device or board vendor and validate that the running kernel includes the upstream fix.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel or vendor kernel package includes the patched stratix10-rsu changes for early return after failed COMMAND_RSU_DCMF_VERSION, COMMAND_RSU_DCMF_STATUS, COMMAND_RSU_MAX_RETRY, and COMMAND_RSU_GET_SPT_TABLE message paths. On Linux systems, check the running kernel version and vendor changelog, inspect the source package if available, or confirm that the relevant patch is present in drivers/firmware/stratix10-rsu.c. Validate exposure by checking whether the platform uses Stratix 10 RSU hardware and whether the driver is present or loaded with commands such as lsmod, modinfo, dmesg, and checks under /sys/bus/platform/drivers. After patching, reboot into the fixed kernel and verify there are no recurring stratix10-rsu probe failures, rsu_send_msg timeouts, NULL pointer dereferences, kernel oopses, or panics in kernel logs.

Typical attack path

1. Identify a Linux system running on affected Intel/Altera Stratix 10 hardware with the stratix10-rsu firmware driver available or loaded.
2. Gain local administrative or otherwise sufficient access to trigger driver probe, device binding, module loading, reboot, or firmware-service interactions.
3. Induce or wait for a timeout in rsu_send_msg() during one of the affected RSU probe commands.
4. Allow the vulnerable error path to free the service channel while execution continues to queue another command on that invalid channel.
5. Trigger the service callback path so the kernel service thread dereferences the NULL channel pointer.
6. Cause a kernel oops, panic, reboot, or device/service outage.

How to detect it

To determine whether the issue was already triggered, review persistent kernel logs, console logs, crash dumps, and reboot history for evidence of stratix10-rsu probe failures followed by a NULL pointer dereference or kernel panic. Useful sources include journalctl -k output, /var/log/kern.log, /var/log/messages, /var/log/syslog, pstore/ramoops records, kdump vmcores, serial console logs, hypervisor or BMC event logs, and watchdog reset records. Look for sequences where RSU firmware commands time out during probe, the stratix10 service driver reports errors, and a kernel oops occurs in or near stratix10_rsu_probe, rsu_send_msg, rsu_send_async_msg, stratix10_svc, or related callback/kthread paths. Also check for repeated module load/unload, driver bind/unbind, or reboots around the time of the crash, which may indicate deliberate triggering or unstable firmware behavior. There are no known network indicators for this vulnerability; detection is host- and kernel-log focused.

• stratix10-rsu
• stratix10_rsu_probe
• rsu_send_msg
• rsu_send_async_msg
• COMMAND_RSU_DCMF_VERSION
• COMMAND_RSU_DCMF_STATUS
• COMMAND_RSU_MAX_RETRY
• COMMAND_RSU_GET_SPT_TABLE
• stratix10_svc_free_channel
• stratix10_svc_remove_async_client
• NULL pointer dereference
• Unable to handle kernel NULL pointer dereference
• BUG: kernel NULL pointer dereference
• Kernel panic - not syncing
• Oops:
• stratix10-svc
• /sys/bus/platform/drivers/stratix10-rsu
• drivers/firmware/stratix10-rsu.c
• pstore
• ramoops

What your security team should do

• Inventory Linux systems using Intel/Altera Stratix 10 platforms or kernels that build or ship the stratix10-rsu driver.
• Prioritize patching affected embedded, industrial, network, and edge systems where an unexpected kernel crash would cause operational disruption or require manual recovery.
• Deploy vendor-provided fixed kernel images or backport the upstream driver patch into custom kernels.
• If RSU functionality is not needed, disable or blacklist the stratix10-rsu module as a temporary mitigation.
• Restrict local administrative access and kernel module loading capabilities to trusted operators only.
• Monitor kernel logs for stratix10-rsu probe failures, RSU service message timeouts, NULL pointer dereferences, kernel oopses, and unexpected reboots.
• Because this issue is not in CISA KEV, has low EPSS, and has no known public exploit, treat it as a targeted reliability and availability risk rather than an internet-scale emergency unless affected devices are mission-critical.