CVE-2026-43145

What it actually does

This is a local denial-of-service flaw in the Linux kernel i.MX remoteproc driver. When a device tree defines an "rsc-table" location but the firmware currently being started does not actually provide a resource table, the driver can incorrectly return a stale or assumed resource-table pointer. The remoteproc core then treats that pointer as valid and may dereference invalid state, causing a kernel crash when starting affected remote processor firmware. The impact is availability loss only; the provided CVSS vector does not indicate confidentiality or integrity impact.

Why it matters to the business

Systems using affected Linux kernels with NXP i.MX remoteproc functionality may be crashed by a local user or process with the ability to start or manage remote processor firmware. The most likely operational impact is device reboot, service interruption, loss of availability, and disruption to embedded, industrial, edge, or appliance workloads that depend on i.MX remote processors. The risk is lower for general-purpose Linux servers that do not use the affected i.MX remoteproc driver or do not expose remoteproc management to untrusted local users. This issue is not listed in CISA KEV, is not known to be used in ransomware campaigns, has very low EPSS, and has no known public exploit maturity based on the supplied data.

How an attack unfolds

An attacker first needs local access with sufficient privilege to interact with remoteproc firmware management, such as through sysfs interfaces, service tooling, or another local mechanism that can start firmware on an affected i.MX remote processor. The attacker then causes the system to start firmware that does not contain a resource table while the platform device tree still defines an "rsc-table" entry. In vulnerable kernels, the i.MX remoteproc driver can report a loaded resource table even though the current firmware did not provide one. The remoteproc core proceeds as if the table is valid, which can trigger an invalid access or inconsistent kernel state and crash the kernel. The end result is a local denial of service rather than code execution.

How to fix it

Apply a Linux kernel update that includes the upstream fix for the i.MX remoteproc resource-table validation logic. The corrected behavior is to return NULL from imx_rproc_elf_find_loaded_rsc_table() when rproc->table_ptr is NULL, so the remoteproc core does not treat a nonexistent firmware resource table as valid. If vendor fixed package versions are not yet available, track the affected distribution, BSP, appliance, or device vendor advisory and deploy the first kernel or firmware bundle containing this fix. As interim mitigation, restrict local access to remoteproc management interfaces, limit who can write or select remote processor firmware, avoid starting untrusted or malformed firmware, and disable unused remoteproc functionality on platforms that do not require it.

How to confirm the fix worked

Confirm that the running kernel contains the remoteproc i.MX fix by checking the vendor advisory, kernel changelog, package changelog, or source tree for the change in imx_rproc_elf_find_loaded_rsc_table() that returns NULL when rproc->table_ptr is NULL. Validate exposure by confirming whether the system uses i.MX remoteproc hardware and whether the imx_rproc driver is present or loaded. Check for remoteproc sysfs entries and device tree "rsc-table" properties on applicable embedded platforms. After patching, test starting firmware that lacks a resource table in a controlled environment and verify that the system no longer crashes.

Typical attack path

1. Identify a Linux system using an affected kernel with the i.MX remoteproc driver enabled and active.
2. Obtain local access with permission to load, configure, or start remote processor firmware.
3. Select or provide firmware for the remote processor that does not include a resource table.
4. Trigger remoteproc start or restart through available management interfaces.
5. Cause the vulnerable driver to return an invalid loaded resource-table pointer.
6. Crash the kernel or destabilize the system, resulting in denial of service.

How to detect it

To determine whether this issue may have been exploited, review kernel logs, persistent journal logs, serial console captures, crash dumps, and watchdog reset records from affected i.MX-based systems. Focus on events where a remote processor was started or restarted shortly before a kernel oops, panic, watchdog reset, or unexpected reboot. Relevant sources include dmesg output, journald/kern.log, embedded device console logs, pstore/ramoops records, kdump/vmcore artifacts, and audit logs showing writes to remoteproc sysfs controls. Look for stack traces or messages involving remoteproc, imx_rproc, resource table handling, or firmware start operations. Because this vulnerability causes a crash and does not leave a stable post-exploitation payload, absence of persistent files or network indicators does not rule it out. Correlate crash timing with local users, services, scripts, or update agents that modified firmware names, wrote to remoteproc state controls, or deployed firmware images without resource tables.

• imx_rproc_elf_find_loaded_rsc_table
• imx_rproc
• remoteproc
• rsc-table
• resource table
• /sys/class/remoteproc/
• /sys/class/remoteproc/remoteproc*/state
• /sys/class/remoteproc/remoteproc*/firmware
• /sys/kernel/debug/remoteproc/
• Kernel panic
• kernel BUG
• Oops:
• Unable to handle kernel NULL pointer dereference
• watchdog: watchdog did not stop
• pstore
• ramoops

What your security team should do

• Prioritize patching affected embedded, edge, appliance, and industrial Linux systems that use NXP i.MX remoteproc functionality.
• Inventory systems for active remoteproc usage, loaded imx_rproc-related modules, and remoteproc sysfs interfaces.
• Restrict local users and services that can write firmware, select firmware, or start remote processors.
• Ensure only trusted, vendor-approved remote processor firmware is deployed.
• Monitor kernel logs for remoteproc errors, kernel oops events, panics, or unexpected reboots on i.MX-based systems.
• For products built from custom kernels or BSPs, backport the upstream fix if a full kernel upgrade is not immediately feasible.
• Treat this as an availability risk with low current exploitation likelihood, but prioritize systems where downtime has safety, production, or service-level consequences.