The Linux kernel driver for the ARM Ethos‑U accelerator allocates a job completion fence without validating job buffers. Errors after the allocation trigger a cleanup path that frees the job but leaks the uninitialized fence. Additionally, a scheduler race allows the job run routine to return before the fence is fully initialized, resulting in a zero‑refcount dwarf that is passed to the fence finalizer. These errors can lead to kernel memory corruption or a subtle resource leak that may cause out‑of‑balance refcount handling, eventually resulting in a kernel panic or a denial‑of‑service condition. The vulnerability directly affects the integrity and availability of the kernel’s synchronization primitives and exposes the system to crashes or memory inconsistencies whenever a user or application submits a job to the Ethos‑U device.

The flaw exists in the Linux:Linux kernel, specifically within the accel/ethosu component that manages Ethos‑U accelerator jobs. Any system that runs a kernel version containing the unpatched Ethos‑U driver—commonly used on ARM‑based embedded or mobile devices—could be affected. The vendor product list does not specify exact kernel releases, so administrators should check whether their current kernel pulls in the accel/ethosu code and whether it matches the commit that introduced the fix.

The EPSS score is listed as less than 1 %, indicating a very low probability of exploitation, and the vulnerability is not flagged in the CISA KEV catalog. No CVSS score is provided, but the potential to trigger a kernel panic or memory corruption suggests a moderate severity. The likely attack vector is local: an attacker with access to the Ethos‑U control interface (through the ioctl API) could submit malformed jobs. If the device is exposed via a network‑bound daemon or service, remote exploitation may also be feasible. Given the resource leak and possible crash, the risk is tempered by the low exploitation probability, but the impact of a kernel panic warrants prompt action.