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: accel/ivpu: Fix signed integer truncation in IPC receive
Date: Thu, 04 Jun 2026 16:40:23 +1000
Message-ID: <review-patch1-20260529115453.132291-1-andrzej.kacprowski@linux.intel.com>
In-Reply-To: <20260529115453.132291-1-andrzej.kacprowski@linux.intel.com>
References: <20260529115453.132291-1-andrzej.kacprowski@linux.intel.com> <20260529115453.132291-1-andrzej.kacprowski@linux.intel.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

**Correctness: Good.**

The bug is real. Looking at the kernel tree (`ivpu_ipc.h:38`), `data_size` =
is declared as `u32`:

```c
struct ivpu_ipc_hdr {
    u32 data_addr;
    u32 data_size;
    ...
};
```

The original code at `ivpu_ipc.c:283`:
```c
u32 size =3D min_t(int, rx_msg->ipc_hdr->data_size, sizeof(*jsm_msg));
```

`min_t(int, ...)` casts both arguments to `int`. If `data_size >=3D 0x80000=
000`, the cast to `int` produces a negative value. Since `sizeof(*jsm_msg)`=
 is positive, `min_t` picks the negative value. That negative `int` is then=
 assigned to `u32 size`, wrapping to a very large unsigned value. The `memc=
py` at line 291 then overflows `jsm_msg`:

```c
if (jsm_msg)
    memcpy(jsm_msg, rx_msg->jsm_msg, size);
```

The fix:
```c
u32 size =3D min_t(u32, rx_msg->ipc_hdr->data_size, sizeof(*jsm_msg));
```

This is correct =E2=80=94 both `data_size` and `sizeof()` are naturally uns=
igned, so `u32` is the appropriate comparison type. The result is always cl=
amped to at most `sizeof(*jsm_msg)`.

**Commit message:** Clear and accurate. The Fixes tag and stable Cc are app=
ropriate. The `# v6.18+` annotation on the stable Cc indicates this only ap=
plies from v6.18 onwards, which matches the referenced commit.

**Minor observation (not a blocking concern):** The `data_size` value comes=
 from firmware, which is a trust boundary. While this fix correctly prevent=
s the overflow, there's no explicit validation that `data_size` is sane (e.=
g., not wildly larger than expected but still < 0x80000000). The `min_t(u32=
, ...)` fix handles this case too since it clamps to `sizeof(*jsm_msg)`, so=
 this is a defense-in-depth comment rather than a problem with the patch.

Reviewed-by worthy as-is.

---
Generated by Claude Code Patch Reviewer