From mboxrd@z Thu Jan 1 00:00:00 1970 From: Claude Code Review Bot To: dri-devel-reviews@example.com Subject: Claude review: accel/ethosu: fix integer overflow in dma_length() Date: Mon, 25 May 2026 17:08:44 +1000 Message-ID: In-Reply-To: <20260524051659.70654-1-meatuni001@gmail.com> References: <20260524051659.70654-1-meatuni001@gmail.com> <20260524051659.70654-1-meatuni001@gmail.com> X-Mailer: Claude Code Patch Reviewer Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Patch Review This is v1 and is **superseded by v3**. It only addresses multiplication ov= erflow: ```c - len *=3D dma_st->size0; + if (check_mul_overflow(len, (u64)dma_st->size0, &len)) + return U64_MAX; ``` **Issues in v1:** 1. **Missing negative stride underflow check.** Before the multiplication, = `len +=3D dma->stride[0]` adds a signed `s64` to an unsigned `u64`. If `str= ide[0]` is a large negative value (sign-extended from 40-bit input), this w= raps `len` to a huge value. With `size0 =3D=3D 1`, `check_mul_overflow` doe= s not trigger, and the result is a garbage length. 2. **Missing caller validation.** The commit message claims "the callers of= dma_length() already treat U64_MAX as an error sentinel," but looking at t= he caller at the original line 397=E2=80=93400 (now line 407), `srclen`/`ds= tlen` were only used in a `dev_dbg()` format string =E2=80=94 the return va= lue was never checked for `U64_MAX`. This means even when `dma_length()` re= turns `U64_MAX`, the `info->region_size[]` entry would remain at 0 (never u= pdated because the function returned early), and the region would be skippe= d entirely by `ethosu_job.c` at line 420/670, allowing stale physical addre= sses through. This claim in the commit message is **incorrect** for the `NP= U_OP_DMA_START` case. 3. **Missing `len + dma->offset` overflow check** at the `region_size` upda= te. --- Generated by Claude Code Patch Reviewer