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

[PATCH] 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_t(u32, ...) to ensure large values are
properly clamped instead of becoming negative.

Fixes: 3b434a3445ff ("accel/ivpu: Use threaded IRQ to handle JOB done messages")
Cc: <stable@vger.kernel.org> # v6.18+
Signed-off-by: Andrzej Kacprowski <andrzej.kacprowski@linux.intel.com>
---
 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..9980a7898bed 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_t(u32, 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

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

[Wachowski, Karol]

On 29-May-26 13:54, Andrzej Kacprowski wrote:
> 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_t(u32, ...) to ensure large values are
> properly clamped instead of becoming negative.
> 
> Fixes: 3b434a3445ff ("accel/ivpu: Use threaded IRQ to handle JOB done messages")
> Cc: <stable@vger.kernel.org> # v6.18+
> Signed-off-by: Andrzej Kacprowski <andrzej.kacprowski@linux.intel.com>

Reviewed-by: Karol Wachowski <karol.wachowski@linux.intel.com>

> ---
>   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..9980a7898bed 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_t(u32, 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);

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