CVE-2026-53173

What it actually does

This is a local kernel heap out-of-bounds write in the Linux kernel Ethos-U accelerator driver command-stream validation path. A user-controlled ioctl supplies both the command buffer contents and size; when a command word has the 64-bit-command flag set at the final 32-bit slot, the driver increments its index and writes one additional 32-bit word past the end of a DMA-backed GEM allocation. The immediate primitive is a controlled 4-byte write beyond the allocated buffer in kernel context. Practical outcomes can include kernel memory corruption, system crash, or potentially local privilege escalation depending on kernel configuration, allocator state, adjacent objects, and exploit mitigations.

Why it matters to the business

Systems using Linux kernels with the vulnerable Ethos-U accelerator driver enabled may be exposed to local denial of service or privilege escalation by a user or process that can access the accelerator device interface. The vulnerability is not listed in CISA KEV, is not reported as ransomware-used, has very low EPSS, and has no known public exploit maturity in the provided data, so broad internet-scale exploitation is unlikely; however, it remains important for multi-user systems, edge/AI appliances, embedded Linux platforms, and workloads where untrusted code may run locally.

How an attack unfolds

An attacker first obtains local execution on a system where the vulnerable Ethos-U accelerator driver is present and reachable through its device/ioctl interface. The attacker opens the relevant accelerator/DRM device and submits a crafted command stream with a size that exactly fills the allocated command buffer. The last 32-bit command word is crafted so the driver treats it as the first half of a 64-bit command. During validation, the kernel writes the final in-bounds word, increments the index, then writes the second word one slot past the DMA allocation. This corrupts adjacent kernel heap memory. In the simplest case this causes a kernel warning, panic, or device/driver failure; with careful heap shaping and favorable conditions, the corruption could be used as part of a local privilege-escalation chain.

How to fix it

Update to a Linux kernel version or vendor kernel package that includes the fix for the Ethos-U driver command-stream bounds check. If a fixed kernel is not yet available for the platform, backport the upstream patch that validates the incremented command index before writing the second 32-bit word and returns an error for undersized extended commands. As interim risk reduction, disable or unload the Ethos-U accelerator driver where it is not required, remove access to the affected device nodes from untrusted users and containers, and enforce least-privilege device cgroup, udev, and container runtime policies so only trusted workloads can access accelerator interfaces.

How to confirm the fix worked

Confirm the running kernel or vendor kernel package includes the patched Ethos-U driver. Validate that the affected function rejects a command stream ending with an incomplete 64-bit command and returns an error such as EINVAL rather than performing the second write. On test systems, run the malformed command-stream case with KASAN, KFENCE, or other kernel memory debugging enabled and verify there is no out-of-bounds write report. Also verify that unnecessary Ethos-U modules are not loaded and that device node permissions prevent untrusted users or containers from invoking the accelerator ioctl interface.

Typical attack path

1. Gain local code execution on a Linux system with the vulnerable Ethos-U accelerator driver enabled.
2. Confirm the attacker-controlled process can open the accelerator/DRM device node or otherwise invoke the affected ioctl.
3. Allocate or trigger creation of a command-stream GEM/DMA buffer of a chosen size.
4. Submit a crafted command stream where the final command word sets the extended-command bit requiring a second 32-bit word.
5. Trigger the vulnerable validation loop so the driver writes four bytes past the end of the allocated buffer.
6. Use the resulting kernel memory corruption to crash the system or attempt privilege escalation through heap manipulation.

How to detect it

Detection should focus on local exploitation artifacts because this issue is triggered through a kernel ioctl rather than over the network. Review kernel logs, persistent journal entries, crash dumps, pstore/ramoops output, and EDR telemetry for kernel memory-corruption events involving the Ethos-U driver or accelerator device access shortly before a crash. Look for KASAN, KFENCE, slab, page allocator, general protection fault, oops, BUG, panic, or use-after-corruption messages with stack traces that include ethosu_gem_cmdstream_copy_and_validate or related Ethos-U command-stream handling. Correlate those events with local process execution, container activity, device-node opens, and ioctl-heavy access to accelerator/DRM devices. There are no reliable network indicators for this vulnerability, and absence of logs does not prove absence of exploitation because successful privilege escalation may not leave a distinctive artifact.

• ethosu_gem_cmdstream_copy_and_validate
• accel/ethosu
• ethosu
• KASAN: slab-out-of-bounds
• KASAN: out-of-bounds
• BUG: KASAN
• KFENCE: memory corruption
• kernel BUG at
• general protection fault
• Oops:
• Kernel panic
• slab-out-of-bounds
• drm_gem_dma_create
• /dev/accel
• /dev/dri

What your security team should do

• Prioritize patching systems that expose Ethos-U accelerator devices to local users, containers, AI workloads, embedded applications, or other less-trusted code.
• Inventory Linux kernels and kernel configurations for the Ethos-U accelerator driver and determine whether the vulnerable code is built in or available as a loadable module.
• Apply vendor kernel updates or backport the bounds-check fix; track appliance, embedded, and edge-device firmware updates separately because they may lag mainline kernel fixes.
• Restrict access to accelerator/DRM device nodes using udev rules, Unix permissions, groups, device cgroups, and container runtime policies until patched.
• Monitor kernel logs for memory corruption, KASAN, oops, panic, or crash events mentioning Ethos-U or the affected function.
• Treat suspicious local crashes involving the accelerator driver as potential exploitation attempts, especially on multi-tenant or containerized systems.
• Because no KEV listing, ransomware usage, or mature exploit is reported in the provided data, handle as a targeted/local privilege-escalation risk rather than an internet-exposed emergency unless the device interface is reachable by untrusted workloads.