Claude review: accel/ethosu: reject DMA commands with uninitialized length

[Claude Code Review Bot <claude-review@example.com>]

Patch Review

**The fix itself is correct and well-placed:**

```c
+	if (len == U64_MAX)
+		return U64_MAX;
```

Adding this check at line 166 (before the stride arithmetic at lines 167-172) prevents `U64_MAX` from wrapping through addition and multiplication, which is the right approach. It's consistent with the sentinel pattern used elsewhere in the driver (e.g., `feat_matrix_length()` checks `fm->base[tile] == U64_MAX` at line 213).

**Commit message inaccuracies:**

1. The message says *"The caller's U64_MAX check then passes"* — but looking at the `NPU_OP_DMA_START` handler (lines 395-403), there is **no** U64_MAX check on the return value of `dma_length()`. The values `srclen`/`dstlen` are computed and logged but never validated. The only downstream protection is the `region_size` bounds check in `ethosu_job.c:453`, which compares against the GEM buffer size.

2. The message says *"region_size[] stays 0"* — this is actually correct only when `dma->region` is `-1` (the `0xff` sentinel for `s8`), because the `dma->region >= 0` guard at line 174 prevents the `region_size` update. But in that case the DMA wouldn't reference any region at all. If userspace sets a valid `dma->region` but omits `NPU_SET_DMA0_LEN`, the wrapped small value *would* be written to `region_size`, which is the more interesting attack vector — and this patch does correctly fix that case.

**Incomplete fix — no validation at the DMA caller:**

The `NPU_OP_DMA_START` handler at line 395 does not check whether `dma_length()` returned `U64_MAX`. Compare with how `feat_matrix_length()` return values are checked in `calc_sizes()`. After this patch, `dma_length()` correctly returns `U64_MAX` for uninitialized lengths, but nothing in the DMA path actually acts on that sentinel. The `region_size` write is skipped (due to `region >= 0` guard), and execution continues normally. A more complete fix would add:

```c
case NPU_OP_DMA_START:
    srclen = dma_length(info, &st.dma, &st.dma.src);
    dstlen = dma_length(info, &st.dma, &st.dma.dst);
+   if (srclen == U64_MAX || dstlen == U64_MAX)
+       return -EINVAL;
```

**Minor style note:** The patch applies cleanly against the diff context shown, and the 3-line addition is minimal and non-invasive. The `Fixes:` tag and `Cc: stable` are appropriate if the maintainers agree this is a security-relevant fix.

**Summary:** The arithmetic hardening in `dma_length()` is correct and worth having, but the commit message's exploitation narrative doesn't fully match the code. The author should also consider adding explicit U64_MAX validation in the `NPU_OP_DMA_START` handler to make the defense complete, similar to how other operation handlers validate their length computations.

---
Generated by Claude Code Patch Reviewer