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

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

[Muhammad Bilal]

The command stream parsing loop increments the index variable a second
time when a 64-bit command word is encountered (bit 14 set), but does
not re-check the loop bound before writing the second word:

    for (i = 0; i < size / 4; i++) {
        bocmds[i] = cmds[0];
        if (cmd & 0x4000) {
            i++;
            bocmds[i] = cmds[1];   /* unchecked */
        }
    }

The buffer bocmds is backed by a DMA allocation of exactly size bytes
from drm_gem_dma_create(ddev, size), giving valid indices [0, size/4-1].

When i == size/4 - 1 on entry to an iteration and bit 14 of cmds[0] is
set, bocmds[size/4-1] is written in bounds, i is then incremented to
size/4, and bocmds[size/4] writes four bytes past the end of the
allocation.

Userspace controls both the buffer contents and the size argument via
the ioctl, making this a userspace-triggerable heap out-of-bounds write.

Fix by checking the incremented index against the buffer bound before
the second write and returning -EINVAL if the buffer is too small to
contain the extended command.

Fixes: 5a5e9c0228e6 ("accel: Add Arm Ethos-U NPU driver")
Cc: stable@vger.kernel.org
Signed-off-by: Muhammad Bilal <meatuni001@gmail.com>
---
 drivers/accel/ethosu/ethosu_gem.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/accel/ethosu/ethosu_gem.c b/drivers/accel/ethosu/ethosu_gem.c
index 7994e7073903..f526f4aedffd 100644
--- a/drivers/accel/ethosu/ethosu_gem.c
+++ b/drivers/accel/ethosu/ethosu_gem.c
@@ -387,6 +387,8 @@ static int ethosu_gem_cmdstream_copy_and_validate(struct drm_device *ddev,
 				return -EFAULT;
 
 			i++;
+			if (i >= size / 4)
+				return -EINVAL;
 			bocmds[i] = cmds[1];
 			addr = cmd_to_addr(cmds);
 		}
-- 
2.53.0

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

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@gmail.com> 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