From mboxrd@z Thu Jan  1 00:00:00 1970
From: Claude Code Review Bot <claude-review@example.com>
To: dri-devel-reviews@example.com
Subject: Claude review: media: pluto2: fix potential buffer overflow in pluto_dma_end()
Date: Wed, 25 Mar 2026 07:58:45 +1000
Message-ID: <review-patch1-20260323102920.19937-1-Dmitry.Chumachenko@cyberprotect.ru>
In-Reply-To: <20260323102920.19937-1-Dmitry.Chumachenko@cyberprotect.ru>
References: <20260323102920.19937-1-Dmitry.Chumachenko@cyberprotect.ru> <20260323102920.19937-1-Dmitry.Chumachenko@cyberprotect.ru>
X-Mailer: Claude Code Patch Reviewer
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Patch Review

**Assessment: Good fix, minor nit**

The bug is real. `TS_DMA_BYTES` is `188 * 8 =3D 1504`, and `dma_buf` is dec=
lared as `u8 dma_buf[TS_DMA_BYTES]` (line 111). The original loop:

```c
while (pluto->dma_buf[i] =3D=3D 0x47)
    i +=3D 188;
```

increments `i` by 188 each iteration. If every 188th byte happens to be `0x=
47`, `i` would reach `188 * 8 =3D 1504 =3D TS_DMA_BYTES`, and the next iter=
ation would read `pluto->dma_buf[1504]` =E2=80=94 one byte past the end of =
the buffer. The fix:

```c
while (i < TS_DMA_BYTES && pluto->dma_buf[i] =3D=3D 0x47)
    i +=3D 188;
```

correctly bounds-checks before accessing the buffer. Short-circuit evaluati=
on ensures `dma_buf[i]` is never accessed when `i >=3D TS_DMA_BYTES`.

**Minor observation:** In practice, the maximum valid `i` after the loop wo=
uld be `TS_DMA_BYTES` (1504), and `nbpackets =3D 1504 / 188 =3D 8 =3D TS_DM=
A_PACKETS`, which is the correct maximum. So the fix is semantically clean =
=E2=80=94 it doesn't change behavior for valid data, only prevents the OOB =
read.

**Verdict:** Straightforward and correct one-line fix. The commit message, =
Fixes tag, and Signed-off-by are all proper.

Reviewed-by assessment: **Accept**.

---
Generated by Claude Code Patch Reviewer