Thank you for your contribution! Sashiko AI review found 1 potential issue(s) 
to consider:

Pre-existing issues:
- [High] The driver under-estimates the required IFM memory bounds by 
improperly subtracting padding (such as pad_right and pad_bottom), allowing a 
maliciously crafted command stream to read out of bounds.
--

commit 07909a86c51957cbbafa4aac05851fba1d3dae6d
Author: Rob Herring (Arm) <[email protected]>

accel: ethosu: Account for kernel dilation in IFM size

The commit updates calc_sizes() in the Arm Ethos-U NPU driver to account
for kernel dilation settings when calculating the required input feature-map
bounds. It extracts x and y dilation from the kernel stride and multiplies
them with the IFM dimensions to prevent a command stream using dilation
from accessing IFM memory past the driver-validated range.

> diff --git a/drivers/accel/ethosu/ethosu_gem.c 
> b/drivers/accel/ethosu/ethosu_gem.c
> index 9c86f9062f55e..578d1b5b955cf 100644
> --- a/drivers/accel/ethosu/ethosu_gem.c
> +++ b/drivers/accel/ethosu/ethosu_gem.c
> @@ -567,10 +567,16 @@ static int calc_sizes(struct drm_device *ddev,
[ ... ]
>               s32 ifm_height = st->ofm.height[2] * stride_y +
> -                     st->ifm.height[2] - (st->ifm.pad_top + 
> st->ifm.pad_bottom);
> +                     st->ifm.height[2] * dilation_y -
> +                     (st->ifm.pad_top + st->ifm.pad_bottom);
>               s32 ifm_width = st->ofm.width * stride_x +
> -                     st->ifm.width - (st->ifm.pad_left + st->ifm.pad_right);
> +                     st->ifm.width * dilation_x -
> +                     (st->ifm.pad_left + st->ifm.pad_right);

[Severity: High]
This is a pre-existing issue, but does this calculation under-estimate the
required IFM memory bounds by improperly subtracting padding parameters?

Since pad_top, pad_bottom, pad_left, and pad_right are user-provided
values (potentially up to 255), subtracting them here artificially reduces
ifm_height and ifm_width.

When feat_matrix_size() later validates the memory up to
min(ifm_width, fm->width0), this smaller ifm_width could allow a maliciously
crafted command stream to pass validation on a small buffer.

Meanwhile, the NPU hardware might access out of bounds up to the true
coordinate bounded by fm->width0. Could this lead to NPU crashes, page
faults, or information leaks from reading outside the allocated buffer?

-- 
Sashiko AI review ยท 
https://sashiko.dev/#/patchset/[email protected]?part=16

Reply via email to