CVE-2026-89976 in Linux
Summary
by MITRE • 09/16/2026
In the Linux kernel, the following vulnerability has been resolved:
accel/ethosu: fix job completion fence cleanup
ethosu_ioctl_submit_job() allocates done_fence before validating buffer handles. Errors after allocation call ethosu_job_err_cleanup(), which frees the job but leaks the uninitialized fence.
A scheduler dependency error also lets ethosu_job_run() return before dma_fence_init(). Normal cleanup then passes a zeroed refcount to dma_fence_put().
Release done_fence in the common cleanup path and use dma_fence_was_initialized() to distinguish initialized fences from raw allocations.
[robh: also fix goto]
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/16/2026
The Linux kernel driver for Arm Ethos-U NPU accelerators contains a critical resource management flaw within its job submission ioctl implementation, specifically in the ethosu_ioctl_submit_job function. This vulnerability arises from an incorrect ordering of operations during the initialization and validation phases of a hardware acceleration job. The core issue is that the system allocates a done_fence structure before performing necessary validations on buffer handles. When subsequent validation steps fail due to invalid or inaccessible buffers, the error handling path invokes ethosu_job_err_cleanup. This cleanup routine correctly frees the associated job data structures but fails to release the previously allocated done_fence object. Consequently, this results in a memory leak where kernel heap memory is consumed and never returned to the system pool for each failed submission attempt. In high-throughput scenarios or under sustained attack conditions involving repeated invalid submissions, this unbounded allocation can lead to significant resource exhaustion, potentially degrading system performance or contributing to denial of service conditions through gradual memory depletion.
Beyond the direct memory leak, a more severe logical flaw exists within the scheduler dependency handling logic that affects the lifecycle management of dma_fence objects. Under specific race conditions or error paths involving scheduler dependencies, the ethosu_job_run function may return prematurely before the dma_fence_init routine has been executed to properly initialize the fence structure. This premature exit leaves the done_fence in an uninitialized state with a zeroed reference count. When the standard cleanup path subsequently attempts to release this fence by calling dma_fence_put, it operates on data that was never correctly initialized. Passing a zeroed refcount or operating on an uninitialized object violates the expectations of the kernel's synchronization primitives and can lead to undefined behavior, including potential use-after-free scenarios if other parts of the system attempt to interact with the stale pointer, or simply incorrect accounting of fence references which may prevent proper cleanup later in the execution flow.
The remediation for this vulnerability involves restructuring the error handling logic within the driver to ensure that resource allocation and deallocation are strictly paired regardless of where an error occurs. The fix implements a common cleanup path that explicitly releases the done_fence, ensuring no memory is left orphaned after validation failures. Furthermore, the solution introduces the use of dma_fence_was_initialized as a guard condition. This check allows the driver to distinguish between fences that have been properly initialized via dma_fence_init and those that remain in their raw allocated state with zeroed refcounts. By only calling release functions on verified initialized fences, the code prevents invalid operations on uninitialized structures while ensuring all allocated resources are correctly freed. Additionally, control flow adjustments such as fixing goto statements ensure that execution paths consistently reach these cleanup routines without skipping critical deallocation steps.
From a vulnerability classification perspective, this issue maps to CWE-401 Missing Release of Memory after Effective Lifetime and CWE-362 Concurrent Execution using Shared Resource with Improper Synchronization if the uninitialized access leads to race conditions affecting shared state. The improper handling of kernel resources aligns with ATT&CK technique T1578.002, specifically related to modifying cloud or infrastructure compute instances through resource exhaustion in virtualized environments, although here it applies directly to local kernel memory management. For system administrators and developers maintaining Linux kernels containing the Ethos-U driver, applying this patch is essential to maintain stability and security posture. Mitigation strategies include ensuring that all buffer handle validations occur prior to any non-trivial allocation of synchronization primitives like fences. Developers should also audit similar ioctl handlers for consistent error handling paths that guarantee symmetric resource acquisition and release, utilizing standard kernel helpers such as dma_fence_was_initialized to safely manage object lifecycles without risking undefined behavior or memory leaks.