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

[Muhammad Bilal]

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()?

Muhammad Bilal