Re: [PATCH v3 16/22] accel: ethosu: Account for kernel dilation in IFM size

[sashiko-bot@kernel.org]

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) <robh@kernel.org>

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/20260908-ethosu-fixes-v3-0-490fe215286f@kernel.org?part=16