Re: [PATCH] accel/ethosu: fix OOB write in ethosu_gem_cmdstream_copy_and_validate()

[Rob Herring]

On Sat, May 23, 2026 at 3:15 PM Muhammad Bilal <meatuni001@xxxxxxxxx> wrote:
>
> While reviewing the command stream parser further, I noticed that
> weight[1..3] and scale[1] have their base and length parsed but no
> corresponding WEIGHT1_REGION/SCALE1_REGION commands exist in the UAPI.
> After cmd_state_init() memsets the state to 0xff, their .region field
> stays 0xff and is never assigned, so calc_sizes() never updates
> region_size[] with their extents.
>
> The job submission in ethosu_job.c validates region_size[i] <= gem->size,
> but since secondary weights never wrote into region_size[], a userspace
> caller could supply large base+length values for weight[1..3] or scale[1]
> that exceed the GEM buffer without the kernel catching it.
>
> Does the hardware specification guarantee that weight[1..3] and scale[1]
> are always sub-offsets within weight[0]'s region, or can they reference
> memory independently? If the latter, should their extents be validated
> against region_size[weight[0].region] in calc_sizes()?

There is only 1 weight region and 1 scale region, so the former.

I think we just need to keep a single weight and scale length which is
the max of any base+length.

Rob