Description

In the Linux kernel, the following vulnerability has been resolved: accel: ethosu: Ensure SRAM region size matches job It is possible for userspace to set the job SRAM size to 0, but then still have SRAM accesses in the command stream. When the job SRAM size is 0, setting the region base register is skipped and a stale base address from a prior job is used. Check the region size against the job's SRAM size instead of just the size of the SRAM. The job's SRAM size was already checked against the total SRAM size.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.8",
  "pubDate": "2026-09-25T11:17:18.070Z",
  "pubdate": "2026-09-25T11:17:18.070Z",
  "executiveSummary": "This vulnerability exists in the Linux kernel Ethos-U accelerator driver, stemming from improper validation of SRAM region parameters during job submission.\nA local user with access to the Ethos-U device can manipulate the job SRAM size to zero, triggering a logic error that bypasses base register configuration.\nThe primary risk involves the kernel inadvertently utilizing a stale base address from a previous execution context, which may lead to out-of-bounds memory access within the accelerator's peripheral address space.\nThe vulnerability requires local access to the device node, effectively enabling an attacker to influence memory mapping behavior of the hardware accelerator.\nSuccessful exploitation could potentially lead to information disclosure or memory corruption if the stale address points to sensitive regions, impacting system stability or security boundaries enforced by the kernel driver.",
  "technicalDetails": "The root cause of the vulnerability resides in the validation logic within the Ethos-U driver's command stream processing component. When a userspace application constructs a job, it provides parameters governing SRAM utilization. The driver previously validated the requested SRAM size against the physical limits of the total device SRAM but failed to ensure that the assigned region base address remained consistent with the specific job configuration.\nSpecifically, when a userspace process specifies a job SRAM size of zero, the driver logic incorrectly bypasses the write operation intended to update the region base register. Because the driver relies on the existing state of these hardware registers for execution, the omission of a mandatory update causes the hardware to retain the base address configured for a prior, potentially unrelated, job.\nThe attack flow proceeds as follows: First, an attacker performs an initial operation with a valid, non-zero SRAM configuration, causing the kernel to populate the SRAM region base registers with a specific address. Second, the attacker submits a subsequent job with the SRAM size explicitly set to zero. Due to the faulty logic, the driver skips the reconfiguration of the base register. Third, when the hardware executes the command stream, it uses the stale base address from the previous job while processing instructions that likely expect the zero-size configuration. If the command stream includes memory access instructions, these accesses may be directed to incorrect or unauthorized memory locations based on the inherited, stale pointer.\nThis behavior represents a failure in state synchronization between the kernel driver and the hardware accelerator. By controlling the initial state through legitimate job submissions and then triggering the zero-size path, an attacker can coerce the driver into using stale register states. This effectively confuses the hardware's memory mapping, potentially allowing for unauthorized read or write operations within the range accessible by the accelerator. The impact of this vulnerability is bounded by the capabilities of the Ethos-U hardware and the privileges of the user interacting with the device driver, necessitating local user access to the hardware interface."
}