CVE-2026-53169: Linux Ethos-U NPU Driver DoS via Unimplemented Command

Technical summary

The accel/ethosu driver contains a WARN_ON(1) placeholder in the NPU_OP_RESIZE command path. This command is U85-specific and not yet implemented. When userspace submits the command via DRM_IOCTL_ETHOSU_GEM_CREATE ioctl, the warning fires unconditionally, filling kernel logs and—if panic_on_warn is enabled—panicking the kernel. The vulnerability stems from using a debug assertion as a temporary safeguard rather than returning a proper error code. The resolution replaces WARN_ON(1) with explicit -EINVAL validation, rejecting the unsupported command before it reaches hardware.

Business impact

Systems running affected Linux kernels with panic_on_warn enabled face elevated availability risk. Any unprivileged user with DRM device access can trigger kernel panics, disrupting services and user sessions. Organizations running machine-learning or AI workloads on Ethos-U hardware (common in embedded and edge deployments) face immediate DoS exposure. Non-panicking systems experience degraded observability through unbounded kernel log spam, potentially masking genuine issues.

Affected systems

The vulnerability affects Linux kernel versions containing the accel/ethosu driver code. The impact is most acute in systems with panic_on_warn configured and those granting unprivileged users access to DRM devices—typical in containers, multi-user workstations, and embedded systems running Ethos-U accelerators. The actual attack surface depends on kernel build configuration and DRM device permissions in your deployment.

Exploitability

Exploitation is straightforward: an unprivileged user with DRM device access (often the default) invokes a single ioctl with an NPU_OP_RESIZE command. On panic_on_warn systems, this immediately crashes the kernel with no additional privileges required. Even without panic_on_warn, repeated invocation floods kernel logs. No special tools or race conditions are necessary—this is a direct, reliable trigger.

Remediation

Update to a Linux kernel version containing the fix that replaces the WARN_ON(1) placeholder with -EINVAL validation. Verify the specific version against your distribution's advisory. As an interim control, restrict DRM device access to trusted users only; limit access via device permissions, SELinux, or AppArmor rules. Disable panic_on_warn if your security posture permits, reducing the severity to log spam rather than availability loss.

Patch guidance

Consult your Linux distribution (Red Hat, Debian, Ubuntu, SUSE, etc.) for kernel updates addressing CVE-2026-53169. Patches will vary by distribution version and release. Apply updates following your organization's kernel patching cycle. For custom or embedded kernels, cherry-pick the fix from upstream Linux or backport from the distribution patch. Test in non-production environments first, as kernel updates may require reboot.

Detection guidance

Monitor for repeated DRM_IOCTL_ETHOSU_GEM_CREATE ioctl invocations with NPU_OP_RESIZE commands from non-privileged processes. In kernel logs, look for WARN messages from the ethosu driver (search for 'ethosu' and 'WARN'). On panic_on_warn systems, kernel panics traceable to the ethosu driver indicate exploitation. Audit DRM device permissions using 'ls -l /dev/dri/*' and restrict as needed. Enable comprehensive DRM/GPU auditing if your organization deploys Ethos-U accelerators.

Why prioritize this

Although CVSS 5.5 is medium severity, the ease of exploitation—a simple ioctl from an unprivileged user—and the availability impact on panic_on_warn systems elevate practical risk. This is especially critical for organizations deploying Ethos-U accelerators in multi-tenant or untrusted-user environments. Prioritize patching systems with panic_on_warn enabled or those granting broad DRM access.

Risk score, explained

CVSS 3.1 assigns 5.5 (MEDIUM) due to local attack vector, low privilege requirement, no complexity, and high availability impact but no confidentiality or integrity harm. The score appropriately reflects that unprivileged users can cause denial-of-service. The lack of KEV designation indicates no known active exploitation, though the simplicity of the attack vector suggests risk is elevated in real-world deployments.

Frequently asked questions