[PATCH v2] accel/ivpu: Fix signed integer truncation in IPC receive

[PATCH v2] accel/ivpu: Fix signed integer truncation in IPC receive

[Andrzej Kacprowski]

Fix potential buffer overflow where firmware-supplied data_size is cast
to signed int before being used in min_t(). Large unsigned values
(>= 0x80000000) become negative, causing unsigned wraparound and
oversized memcpy operations that can overflow the stack buffer.

Change min_t(int, ...) to min() as both values are unsigned and can be
handled by min() without explicit cast.

Fixes: 3b434a3445ff ("accel/ivpu: Use threaded IRQ to handle JOB done messages")
Cc: <stable@vger.kernel.org> # v6.12+
Signed-off-by: Andrzej Kacprowski <andrzej.kacprowski@linux.intel.com>
---
Changes in v2:
- Replaced min_t() with min()

 drivers/accel/ivpu/ivpu_ipc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/accel/ivpu/ivpu_ipc.c b/drivers/accel/ivpu/ivpu_ipc.c
index f47df092bb0d..9347f05a2b79 100644
--- a/drivers/accel/ivpu/ivpu_ipc.c
+++ b/drivers/accel/ivpu/ivpu_ipc.c
@@ -276,7 +276,7 @@ int ivpu_ipc_receive(struct ivpu_device *vdev, struct ivpu_ipc_consumer *cons,
 	if (ipc_buf)
 		memcpy(ipc_buf, rx_msg->ipc_hdr, sizeof(*ipc_buf));
 	if (rx_msg->jsm_msg) {
-		u32 size = min_t(int, rx_msg->ipc_hdr->data_size, sizeof(*jsm_msg));
+		u32 size = min(rx_msg->ipc_hdr->data_size, sizeof(*jsm_msg));
 
 		if (rx_msg->jsm_msg->result != VPU_JSM_STATUS_SUCCESS) {
 			ivpu_err(vdev, "IPC resp result error: %d\n", rx_msg->jsm_msg->result);
-- 
2.43.0

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

[Claude Code Review Bot]

Overall Series Review

Subject: accel/ivpu: Fix signed integer truncation in IPC receive
Author: Andrzej Kacprowski <andrzej.kacprowski@linux.intel.com>
Patches: 1
Reviewed: 2026-06-04T13:53:03.415757

---

This is a single-patch fix for a real integer truncation bug in the Intel VPU (IVPU) IPC receive path. The issue is well-identified: `min_t(int, ...)` casts a `u32` value (`data_size`) to `signed int`, which means values >= 0x80000000 become negative. When that negative value is then used as a `u32` (the type of `size`), it wraps to a very large unsigned value, leading to an oversized `memcpy` at line 291 that could overflow a stack buffer.

The fix is correct and minimal — replacing `min_t(int, ...)` with `min()` — since both operands (`data_size` is `u32`, `sizeof(...)` is `size_t`) are unsigned, making `min()` safe and appropriate here. The Fixes tag, stable backport annotation, and commit message are all well-formed.

**Verdict: This patch looks correct and ready to merge.**

---
Generated by Claude Code Patch Reviewer

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

[Claude Code Review Bot]

Patch Review

**The bug is real and clearly explained.** Looking at the existing code:

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

`rx_msg->ipc_hdr->data_size` is `u32` (confirmed in `ivpu_ipc.h:38`), and `sizeof(*jsm_msg)` is `size_t`. The `min_t(int, ...)` cast truncates both to signed `int`. If firmware-supplied `data_size` is >= 0x80000000, the cast produces a negative value, which "wins" the min comparison, then gets assigned back to `u32 size` as a huge value, and the subsequent `memcpy(jsm_msg, rx_msg->jsm_msg, size)` at line 291 overflows.

**The fix is correct:**

```c
u32 size = min(rx_msg->ipc_hdr->data_size, sizeof(*jsm_msg));
```

- `data_size` is `u32`, `sizeof(...)` is `size_t` (unsigned). The kernel's `min()` macro handles type promotion correctly for unsigned types — `u32` will promote to `size_t` in the comparison, which is safe.
- The result is capped to `sizeof(*jsm_msg)` which fits in `u32`, so the assignment is also safe.

**Minor observations (not blocking):**

- The `sizeof(*jsm_msg)` operand has type `size_t`, while `data_size` has type `u32`. On 64-bit kernels these differ in width. The kernel's `min()` macro (using `__types_ok()`) permits this comparison when both are unsigned and one promotes safely. This works correctly, but if the build bot flags a type mismatch warning (some older kernel versions were stricter), `min_t(u32, ...)` would be the fallback. This should be fine on current kernels.

- The commit message and changelog are clean. The `Fixes:` tag references the correct commit that introduced `min_t(int, ...)`, and the `Cc: stable` annotation with `# v6.12+` is appropriate.

**Reviewed-by recommendation: This patch is correct and suitable for merging.**

---
Generated by Claude Code Patch Reviewer

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

[Claude Code Review Bot]

Overall Series Review

Subject: accel/ivpu: Fix signed integer truncation in IPC receive
Author: Andrzej Kacprowski <andrzej.kacprowski@linux.intel.com>
Patches: 2
Reviewed: 2026-06-04T16:40:23.158315

---

This is a single-patch fix for a signed integer truncation bug in the Intel VPU (IVPU) accelerator driver's IPC receive path. The fix is correct, minimal, and clearly explained. The `data_size` field is a `u32` sourced from firmware, and using `min_t(int, ...)` to compare it against `sizeof(*jsm_msg)` (also unsigned) is a genuine bug: any firmware-supplied value with bit 31 set would be interpreted as negative when cast to `int`, causing `min_t` to select the negative (now-huge-unsigned) value instead of the `sizeof`, leading to a stack buffer overflow via the subsequent `memcpy` at line 291.

The fix is straightforward and appropriate for stable backport. No concerns.

**Verdict: Patch looks good. Recommend acceptance.**

---
Generated by Claude Code Patch Reviewer

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

[Claude Code Review Bot]

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