MEDIUM 5.5

CVE-2026-53204: Linux Kernel Stratix10 RSU NULL Pointer Dereference DoS

The Linux kernel's Stratix10 RSU (Remote System Update) firmware driver contains a NULL pointer dereference vulnerability that can crash the system. When certain initialization messages time out during driver probe, the code incorrectly frees the communication channel but then tries to send additional messages on that same freed channel. The next kernel thread to run will crash when it attempts to access the freed channel structure. This is a local denial-of-service issue affecting systems with Intel Stratix10 hardware.

Source data · NVD / CISA · public domain

CVSS
3.1 · 5.5 MEDIUM · CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Weaknesses (CWE)
CWE-476
Affected products
8 configuration(s)
Published / Modified
2026-06-25 / 2026-07-02

NVD description (verbatim)

In the Linux kernel, the following vulnerability has been resolved: firmware: stratix10-rsu: Fix NULL deref on rsu_send_msg() timeout in probe rsu_send_msg() can return -ETIMEDOUT when wait_for_completion_interruptible_timeout() fires while the SMC call is still pending. In stratix10_rsu_probe(), the error paths for COMMAND_RSU_DCMF_VERSION, COMMAND_RSU_DCMF_STATUS, COMMAND_RSU_MAX_RETRY and COMMAND_RSU_GET_SPT_TABLE call stratix10_svc_free_channel() - which sets chan->scl to NULL - but then fall through and queue the next request on the same channel. The next svc kthread that runs will dereference pdata->chan->scl in its receive callback path, triggering a NULL pointer dereference identical to the one fixed by commit c45f7263100c ("firmware: stratix10-rsu: Fix NULL pointer dereference when RSU is disabled") for the COMMAND_RSU_STATUS path. Apply the same cleanup pattern to the remaining failure paths: remove the async client, free the channel, and return early so no further messages are queued on a channel whose scl has been cleared. While at it, clean up stratix10_rsu_probe() in two ways without changing behavior: - Drop redundant zero-initialization of fields already cleared by devm_kzalloc(): client.receive_cb, status.* and spt0/1_address (INVALID_SPT_ADDRESS is 0x0). - Replace five identical 3-line error-cleanup blocks (stratix10_svc_remove_async_client() + stratix10_svc_free_channel() + return ret) with goto labels (remove_async_client, free_channel), matching the standard kernel resource-unwinding pattern and making it easier to extend the probe sequence without forgetting matching cleanup. Also move init_completion() next to mutex_init() so sync-primitive initialization is grouped before anything that could trigger a callback. --- v2: Add a minor clean-up of the function stratix10_rsu_probe() to have a centralize exit for all the rsu_send_async_msg() and rsu_send_msg().

2 reference(s) · View on NVD →

SEC.co analysis · AI-assisted, reviewed against source

Technical summary

CVE-2026-53204 is a NULL pointer dereference (CWE-476) in the stratix10_rsu_probe() function of the Linux kernel firmware driver. The vulnerability occurs when rsu_send_msg() times out during initialization—specifically in error paths for COMMAND_RSU_DCMF_VERSION, COMMAND_RSU_DCMF_STATUS, COMMAND_RSU_MAX_RETRY, or COMMAND_RSU_GET_SPT_TABLE commands. The probe function calls stratix10_svc_free_channel(), which nullifies the channel's scl (service channel layer) pointer, but execution continues and queues subsequent requests on the now-invalid channel. When the svc kthread's receive callback attempts to dereference pdata->chan->scl, a NULL pointer dereference occurs. The fix applies proper error-unwinding logic with early returns, matching the pattern previously applied to the COMMAND_RSU_STATUS path in commit c45f7263100c.

Business impact

This vulnerability enables local denial of service on systems running the affected Linux kernel versions with Stratix10 hardware. An unprivileged local user can trigger a kernel panic by inducing firmware initialization timeouts, disrupting system availability. The impact is limited to systems with Intel Stratix10 FPGA/SoC hardware; general-purpose servers and client systems are unaffected. The attack requires local access and cannot be exploited remotely.

Affected systems

The Linux kernel is affected across multiple versions. Impact is specific to systems with Intel Stratix10 hardware (FPGA or SoC platforms). General-purpose Linux distributions and servers without Stratix10 devices are not vulnerable. Users must check their kernel version against the upstream fix and confirm whether their systems include Stratix10 hardware.

Exploitability

Exploitability is local-only, requiring existing user-level access (PR:L in CVSS). No authentication bypass or privilege escalation occurs. An attacker with shell access can trigger the vulnerable code path by inducing initialization timeouts on the RSU driver, causing a kernel panic. The attack is not complex (AC:L) and does not require user interaction. The vulnerability is difficult to exploit reliably in production due to the need to trigger specific timing conditions during driver probe.

Remediation

Apply the upstream kernel patch that introduces proper error handling with early returns and goto-based resource cleanup in stratix10_rsu_probe(). The fix prevents further message queueing after the channel is freed by returning early from error paths instead of falling through. Additionally, the patch refactors redundant initialization code and groups synchronization primitive initialization before any callback-triggering code. Verify the patch against your kernel version's upstream repository.

Patch guidance

Identify your running kernel version using 'uname -r'. Check the Linux kernel's upstream repository for commits addressing CVE-2026-53204 in the stratix10-rsu driver (firmware/stratix10-rsu.c). Apply the patch as part of a kernel update; do not attempt manual patching unless you are experienced with kernel compilation. Test thoroughly in a non-production environment before deploying to Stratix10-based systems. Coordinate patching with your firmware and FPGA stack updates to ensure compatibility.

Detection guidance

Monitor kernel logs (dmesg, journalctl) for NULL pointer dereference panics originating from the stratix10-rsu driver, particularly messages referencing 'scl' or the probe function. Watch for repeated system crashes during or shortly after boot on Stratix10 systems. Enable CONFIG_DEBUG_PAGEALLOC and CONFIG_KASAN in kernel builds to increase NULL dereference detection sensitivity. Systems without Stratix10 hardware will not trigger this code path and require no special monitoring.

Why prioritize this

Although rated MEDIUM (CVSS 5.5) due to local-only access requirements and lack of confidentiality/integrity impact, prioritization depends on your environment. If you operate Stratix10-based infrastructure (edge computing, FPGA acceleration platforms, aerospace/defense systems), treat this as HIGH priority for rapid kernel patching to prevent operational downtime. If you run only general-purpose infrastructure, this is a lower-priority background fix bundled into routine kernel updates.

Risk score, explained

The CVSS 3.1 score of 5.5 MEDIUM reflects: (1) Local attack vector (AV:L)—requires shell access; (2) Low attack complexity (AC:L)—no special conditions needed beyond local access; (3) Low privileges (PR:L)—unprivileged user account suffices; (4) No user interaction (UI:N); (5) Unavailability impact only (A:H)—kernel crash disrupts availability; (6) No confidentiality or integrity impact. The score appropriately penalizes the remote-attack vector but acknowledges the DoS severity.

Frequently asked questions

Does this affect my Linux desktop or server if I don't have Stratix10 hardware?

No. This vulnerability is specific to the stratix10-rsu firmware driver, which is only loaded on systems with Intel Stratix10 FPGA or SoC hardware. If you run standard x86, ARM, or other server/desktop systems without Stratix10 devices, this code path is never executed.

What happens if the vulnerability is triggered?

The kernel panics with a NULL pointer dereference, causing an immediate system reboot or crash. No data corruption or privilege escalation occurs, but the system becomes unavailable until the kernel is patched and rebooted.

Can an attacker exploit this remotely?

No. The vulnerability requires local user-level access. Remote users cannot trigger it. It is a local denial-of-service issue only.

How do I know if my Stratix10 system is affected?

Check your kernel version against the upstream Linux repository. If your kernel version predates the fix commit and you are running the stratix10-rsu driver (verify in 'lsmod' output), you are affected. Contact your system vendor or consult the kernel's CVE tracking page for specific version cutoffs.

This analysis is based on publicly available vulnerability information and upstream kernel documentation. CVSS scores, patch versions, and affected product details are sourced from the provided vulnerability record. Organizations should verify patch applicability against their specific kernel versions and hardware configurations before deployment. This vulnerability does not appear on the CISA KEV (Known Exploited Vulnerabilities) list as of the publication date. No public exploit code is known; however, local DoS triggering is straightforward for users with shell access. Always test patches in a non-production environment first. Source: NVD (public-domain), retrieved 2026-08-03. Analysis generated by SEC.co (claude-haiku-4-5).