dri-devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Rob Herring (Arm)" <robh@kernel.org>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v3 13/22] accel: ethosu: Validate all feature map tiles
Date: Tue, 08 Sep 2026 22:14:34 +0000	[thread overview]
Message-ID: <20260908221434.E0F591F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <20260908-ethosu-fixes-v3-13-490fe215286f@kernel.org>

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

Pre-existing issues:
- [High] In `feat_matrix_size()`, the bounds validation for `storage == 1` (NHCWB16) fails to check the maximum `y` coordinate accessed within Tile 0, allowing arbitrary out-of-bounds NPU memory access.
--

commit d083f33a7d240704ac9b7187779f0ac15b49cf73
Author: Rob Herring (Arm) <robh@kernel.org>

accel: ethosu: Validate all feature map tiles

The command-stream validator previously checked only the final feature-map
coordinate, which could leave earlier tile base addresses unchecked for
tiled tensors. This patch checks the final coordinate of every tile touched
by an operation and treats U65 feature maps as 2x2 tiled.

> diff --git a/drivers/accel/ethosu/ethosu_gem.c b/drivers/accel/ethosu/ethosu_gem.c
> index 5d4e897831396..11aa3f4dd0e7d 100644
> --- a/drivers/accel/ethosu/ethosu_gem.c
> +++ b/drivers/accel/ethosu/ethosu_gem.c

[ ... ]

> @@ -434,6 +434,94 @@ static u64 feat_matrix_length(struct ethosu_device *edev,
> +static int feat_matrix_size(struct ethosu_device *edev,
> +			    struct ethosu_validated_cmdstream_info *info,
> +			    struct cmd_state *st, struct feat_matrix *fm,
> +			    enum feat_matrix_type type,
> +			    u32 x, u32 y, u32 c, bool ofm, u64 *max_len)
> +{

[ ... ]

> +	if (storage == 1) {
> +		ret = feat_matrix_check_location(edev, info, st, fm, type, x, 0, c,
> +						 ofm, max_len);
> +		if (ret)
> +			return ret;
> +		if (fm->height[0] < fm->height[1] && fm->height[1] <= y) {

[Severity: High]
This isn't a bug introduced by this patch, but this patch attempts to fix
tile validation and appears to still miss the maximum coordinate of Tile 0
for storage == 1 (NHCWB16).

Does this code fail to validate the upper memory bounds of Tile 0?

When userspace submits a command stream with storage == 1, fm->height[0] > 0,
and an operation maximum y > fm->height[0], the bounds validation evaluates
Tile 0 only at its base (y = 0). It never evaluates min(y, fm->height[0]).

Because the validator calculates the required size for Tile 0 based only on
its first row, it misses the memory offset for subsequent rows up to
fm->height[0]. By supplying an undersized GEM buffer for Tile 0, could an
unprivileged user bypass memory validation and corrupt NPU-accessible memory?

> +			ret = feat_matrix_check_location(edev, info, st, fm, type, x,
> +							 fm->height[1], c, ofm,
> +							 max_len);
> +			if (ret)
> +				return ret;
> +		}
> +		if (fm->height[1] < y) {
> +			ret = feat_matrix_check_location(edev, info, st, fm, type, x,
> +							 fm->height[1] + 1, c, ofm,
> +							 max_len);
> +			if (ret)
> +				return ret;
> +		}
> +	}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260908-ethosu-fixes-v3-0-490fe215286f@kernel.org?part=13

  reply	other threads:[~2026-09-08 22:14 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-08 22:04 [PATCH v3 00/22] accel: ethosu: Another batch of fixes Rob Herring (Arm)
2026-09-08 22:04 ` [PATCH v3 01/22] accel: ethosu: Suspend after initialization Rob Herring (Arm)
2026-09-08 22:18   ` sashiko-bot
2026-09-08 22:04 ` [PATCH v3 02/22] accel: ethosu: Ensure suspended on removal Rob Herring (Arm)
2026-09-08 22:19   ` sashiko-bot
2026-09-08 22:04 ` [PATCH v3 03/22] accel: ethosu: Fix probe error cleanup Rob Herring (Arm)
2026-09-08 22:18   ` sashiko-bot
2026-09-08 22:04 ` [PATCH v3 04/22] accel: ethosu: Disable clocks on PM setup failure Rob Herring (Arm)
2026-09-08 22:18   ` sashiko-bot
2026-09-08 22:04 ` [PATCH v3 05/22] accel: ethosu: Quiesce jobs before scheduler teardown Rob Herring (Arm)
2026-09-08 22:20   ` sashiko-bot
2026-09-08 22:04 ` [PATCH v3 06/22] accel: ethosu: Prevent command stream export Rob Herring (Arm)
2026-09-08 22:04 ` [PATCH v3 07/22] accel: ethosu: Move DMA mode to src/dst struct Rob Herring (Arm)
2026-09-08 22:04 ` [PATCH v3 08/22] accel: ethosu: Track command stream register setup Rob Herring (Arm)
2026-09-08 22:04 ` [PATCH v3 09/22] accel: ethosu: Factor buffer bounds checks Rob Herring (Arm)
2026-09-08 22:04 ` [PATCH v3 10/22] accel: ethosu: Fix NHCWB16 bounds calculation Rob Herring (Arm)
2026-09-08 22:19   ` sashiko-bot
2026-09-08 22:04 ` [PATCH v3 11/22] accel: ethosu: Validate secondary streams Rob Herring (Arm)
2026-09-08 22:22   ` sashiko-bot
2026-09-08 22:04 ` [PATCH v3 12/22] accel: ethosu: Reject unsupported commands Rob Herring (Arm)
2026-09-08 22:04 ` [PATCH v3 13/22] accel: ethosu: Validate all feature map tiles Rob Herring (Arm)
2026-09-08 22:14   ` sashiko-bot [this message]
2026-09-08 22:04 ` [PATCH v3 14/22] accel: ethosu: Account for feature map element size Rob Herring (Arm)
2026-09-08 22:20   ` sashiko-bot
2026-09-08 22:04 ` [PATCH v3 15/22] accel: ethosu: Validate convolution parameter Rob Herring (Arm)
2026-09-08 22:04 ` [PATCH v3 16/22] accel: ethosu: Account for kernel dilation in IFM size Rob Herring (Arm)
2026-09-08 22:14   ` sashiko-bot
2026-09-08 22:04 ` [PATCH v3 17/22] accel: ethosu: Reject reserved command encodings Rob Herring (Arm)
2026-09-08 22:04 ` [PATCH v3 18/22] accel: ethosu: Validate accumulator input Rob Herring (Arm)
2026-09-08 22:23   ` sashiko-bot
2026-09-08 22:04 ` [PATCH v3 19/22] accel: ethosu: Restrict dynamic IFM2 weights Rob Herring (Arm)
2026-09-08 22:24   ` sashiko-bot
2026-09-08 22:04 ` [PATCH v3 20/22] accel: ethosu: Split U65 and U85 DMA length validation Rob Herring (Arm)
2026-09-08 22:04 ` [PATCH v3 21/22] accel: ethosu: Validate OFM transpose Rob Herring (Arm)
2026-09-08 22:04 ` [PATCH v3 22/22] accel: ethosu: Validate resize operations Rob Herring (Arm)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260908221434.E0F591F00A3A@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=robh@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox