CVE-2026-53170

What it actually does

This is a Linux kernel driver input-validation flaw in the Ethos-U accelerator driver. The driver uses U64_MAX as a sentinel value for an uninitialized DMA length, but arithmetic in dma_length() can wrap that sentinel to zero when userspace starts a DMA operation without first setting the DMA length. That bypasses the intended bounds check and may allow the accelerator hardware to perform DMA using stale physical addresses from prior state. Depending on platform configuration, IOMMU isolation, device permissions, and reachable memory mappings, this can lead to unauthorized memory reads or writes, kernel memory corruption, denial of service, or potential local privilege escalation.

Why it matters to the business

Systems exposing the vulnerable Ethos-U accelerator interface to untrusted or lower-privileged local users could be at risk of crashes, data exposure, or privilege escalation. The risk is most relevant to embedded, edge, mobile, IoT, and AI-inference systems that include this kernel driver and allow local applications to submit NPU jobs. EPSS is currently low and there is no known CISA KEV listing or public exploit maturity reported, but kernel DMA flaws should still be treated seriously because successful exploitation can cross process and privilege boundaries.

How an attack unfolds

An attacker needs local access to a system where the vulnerable Ethos-U kernel driver is present and where the attacker can open the accelerator device interface or otherwise submit NPU commands. The attacker crafts a command sequence that initializes a DMA operation but intentionally omits the command that sets the DMA length. Because the driver initialized the length field to U64_MAX, the missing setup should be rejected. Instead, when the attacker starts the DMA operation, the vulnerable length-calculation path performs arithmetic on the sentinel value, causing integer wraparound and returning a small or zero length. The subsequent validation sees no invalid length and no region size to check, allowing the job to proceed. The hardware may then execute DMA using stale physical addresses left from previous state. If the attacker can influence surrounding state or repeatedly trigger the behavior, this may be used to corrupt memory, read data that should not be accessible, or crash the system.

How to fix it

Apply a kernel update that includes the upstream fix for the Ethos-U driver, specifically the change that checks for U64_MAX at the start of dma_length() before performing arithmetic. If a vendor kernel is used, obtain the patched kernel or backported driver fix from the device, distribution, SoC, or appliance vendor. If immediate patching is not possible, mitigate by disabling the Ethos-U accelerator driver where not required, preventing untrusted users or containers from accessing the NPU device node, enforcing strict device cgroup policies, and ensuring IOMMU/SMMU isolation is enabled and correctly configured. Avoid granting broad access to accelerator device files from sandboxes, containers, ML workloads, or plugin-based applications until patched.

How to confirm the fix worked

Confirm the running kernel or vendor firmware includes the patched Ethos-U driver logic that rejects uninitialized DMA length before arithmetic is performed. Validate that the vulnerable driver is either not loaded, not built into the kernel, or updated. Review vendor kernel changelogs, package metadata, source patches, or symbol/source inspection for the dma_length() U64_MAX pre-check. On live systems, verify device permissions for the Ethos-U/NPU interface are restricted to trusted users and services. Where safe test harnesses are available, submit malformed DMA command sequences in a controlled lab and confirm they are rejected rather than reaching DMA execution. Also verify IOMMU/SMMU protections are active for the accelerator device.

Typical attack path

1. Gain local code execution on a system with the vulnerable Linux kernel Ethos-U accelerator driver enabled.
2. Obtain permission to access the accelerator/NPU device interface, such as through device-node permissions, a service, or an application sandbox escape path.
3. Submit a crafted command sequence that omits the DMA length setup command.
4. Issue the DMA start operation while the DMA length remains at the uninitialized sentinel value.
5. Trigger integer wraparound in the driver length calculation so the invalid length is treated as acceptable.
6. Cause the hardware DMA engine to operate using stale physical addresses.
7. Use resulting memory corruption, memory disclosure, or kernel fault behavior to attempt privilege escalation, data theft, or denial of service.

How to detect it

There are no known public exploit indicators or distinctive network indicators for this local kernel driver flaw. Detection should focus on evidence of suspicious local access to the Ethos-U/NPU device interface, malformed or failing accelerator jobs, kernel instability, and DMA/IOMMU fault telemetry. Review auditd, Linux kernel logs, systemd journal, device access logs, container runtime device-mapping events, and application logs from services that use the accelerator. Look for untrusted users or containers opening accelerator device nodes, repeated NPU job failures, kernel oops/panic events near accelerator activity, IOMMU/SMMU translation faults involving the accelerator device, and unexplained privilege changes or crashes after accelerator use. If forensic investigation is required, collect kernel logs, loaded module lists, device-node permissions, process execution history, container device mappings, and any vendor-specific NPU runtime logs.

What your security team should do

• Inventory Linux-based products, embedded devices, edge systems, and AI-inference platforms that include the Ethos-U accelerator driver.
• Prioritize patching systems where local users, containers, third-party applications, ML workloads, or remote management services can indirectly access the accelerator device.
• Restrict access to NPU/accelerator device nodes to trusted service accounts only until patched.
• Disable the Ethos-U driver or accelerator functionality on systems where it is not operationally required.
• Confirm IOMMU/SMMU enforcement for accelerator DMA-capable devices, especially on multi-tenant or application-hosting platforms.
• Monitor for kernel crashes, IOMMU faults, abnormal NPU job failures, and unexpected access to accelerator device files.
• Track vendor kernel advisories and apply backported fixes where upstream kernel versions are not directly used.