[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