Claude review: accel/ivpu: Fix signed integer truncation in IPC receive

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

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 = min_t(int, rx_msg->ipc_hdr->data_size, sizeof(*jsm_msg));
```

`min_t(int, ...)` casts both arguments to `int`. If `data_size >= 0x80000000`, 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 `memcpy` at line 291 then overflows `jsm_msg`:

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

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

This is correct — both `data_size` and `sizeof()` are naturally unsigned, so `u32` is the appropriate comparison type. The result is always clamped to at most `sizeof(*jsm_msg)`.

**Commit message:** Clear and accurate. The Fixes tag and stable Cc are appropriate. The `# v6.18+` annotation on the stable Cc indicates this only applies 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 prevents 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