[PATCH v5] dma-buf: Fix silent overflow for phys vec to sgt

[PATCH v5] dma-buf: Fix silent overflow for phys vec to sgt

[David Hu]

In case MMIO size is bigger than 4G and peer2peer DMA goes
through host bridge, we trigger a code path that assigns the
total linked IOVA (which is greater than 4G) to mapped_len.

Previously, `mapped_len` was declared as 32-bit `unsigned int`.
When accumulating `size_t` lengths, this leads to a silent wrap-around.
This truncation causes truncated lengths to be passed to functions
like `fill_sg_entry()`.

Fix this by changing `mapped_len` to `size_t` (64-bit). While
at it, fix similar potential overflow issues in `calc_sg_nents`
by using `size_t` for `nents` and checking against `UINT_MAX`
and using `unsigned int` for the loop iterator in `fill_sg_entry`
to match.

Fixes: 3aa31a8bb11e ("dma-buf: provide phys_vec to scatter-gather mapping routine")
Cc: stable@vger.kernel.org
Cc: iommu@lists.linux.dev
Reviewed-by: Pranjal Shrivastava <praan@google.com>
Signed-off-by: David Hu <xuehaohu@google.com>
---
Changes in v5:
 - Removed WARN_ON_ONCE from calc_sg_nents() to avoid log noise (Jason).
 - Added explicit check for `!nents` in dma_buf_phys_vec_to_sgt() to
   cleanly return -EINVAL on overflow (Jason).

Changes in v4:
 - Added WARN_ON_ONCE() to the nents overflow check to prevent silent
   failures (Claude Bot).

Changes in v3:
 - Removed leftover sentence fragment from the commit message.
 - Kept `nents = 0` initialization (previously stated as removed in the
   v2 changelog) as it is strictly required for the `+=` accumulation
   loop in `calc_sg_nents()`.

Changes in v2:
 - Fixed 'IVOA' -> 'IOVA' typo and expanded commit message (Claude Bot).
 - Added Reverse Xmas tree formatting (Pranjal).
 - Folded in extra bounds checking for calc_sg_nents() (Pranjal).
 - Folded in type consistency fix for fill_sg_entry() (Pranjal).

 drivers/dma-buf/dma-buf-mapping.c | 15 ++++++++++++---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/drivers/dma-buf/dma-buf-mapping.c b/drivers/dma-buf/dma-buf-mapping.c
index 794acff2546a..607b7998463d 100644
--- a/drivers/dma-buf/dma-buf-mapping.c
+++ b/drivers/dma-buf/dma-buf-mapping.c
@@ -10,7 +10,7 @@ static struct scatterlist *fill_sg_entry(struct scatterlist *sgl, size_t length,
 					 dma_addr_t addr)
 {
 	unsigned int len, nents;
-	int i;
+	unsigned int i;
 
 	nents = DIV_ROUND_UP(length, UINT_MAX);
 	for (i = 0; i < nents; i++) {
@@ -36,7 +36,7 @@ static unsigned int calc_sg_nents(struct dma_iova_state *state,
 				  struct phys_vec *phys_vec, size_t nr_ranges,
 				  size_t size)
 {
-	unsigned int nents = 0;
+	size_t nents = 0;
 	size_t i;
 
 	if (!state || !dma_use_iova(state)) {
@@ -51,6 +51,9 @@ static unsigned int calc_sg_nents(struct dma_iova_state *state,
 		nents = DIV_ROUND_UP(size, UINT_MAX);
 	}
 
+	if (nents > UINT_MAX)
+		return 0;
+
 	return nents;
 }
 
@@ -95,9 +98,10 @@ struct sg_table *dma_buf_phys_vec_to_sgt(struct dma_buf_attachment *attach,
 					 size_t nr_ranges, size_t size,
 					 enum dma_data_direction dir)
 {
-	unsigned int nents, mapped_len = 0;
 	struct dma_buf_dma *dma;
 	struct scatterlist *sgl;
+	size_t mapped_len = 0;
+	unsigned int nents;
 	dma_addr_t addr;
 	size_t i;
 	int ret;
@@ -133,6 +137,11 @@ struct sg_table *dma_buf_phys_vec_to_sgt(struct dma_buf_attachment *attach,
 	}
 
 	nents = calc_sg_nents(dma->state, phys_vec, nr_ranges, size);
+	if (!nents) {
+		ret = -EINVAL;
+		goto err_free_state;
+	}
+
 	ret = sg_alloc_table(&dma->sgt, nents, GFP_KERNEL | __GFP_ZERO);
 	if (ret)
 		goto err_free_state;
-- 
2.54.0.929.g9b7fa37559-goog

RE: [PATCH v5] dma-buf: Fix silent overflow for phys vec to sgt

[Tian, Kevin]

> From: David Hu <xuehaohu@google.com>
> Sent: Tuesday, June 2, 2026 4:00 AM
> 
> In case MMIO size is bigger than 4G and peer2peer DMA goes
> through host bridge, we trigger a code path that assigns the
> total linked IOVA (which is greater than 4G) to mapped_len.
> 
> Previously, `mapped_len` was declared as 32-bit `unsigned int`.
> When accumulating `size_t` lengths, this leads to a silent wrap-around.
> This truncation causes truncated lengths to be passed to functions
> like `fill_sg_entry()`.
> 
> Fix this by changing `mapped_len` to `size_t` (64-bit). While
> at it, fix similar potential overflow issues in `calc_sg_nents`
> by using `size_t` for `nents` and checking against `UINT_MAX`
> and using `unsigned int` for the loop iterator in `fill_sg_entry`
> to match.
> 
> Fixes: 3aa31a8bb11e ("dma-buf: provide phys_vec to scatter-gather mapping
> routine")
> Cc: stable@vger.kernel.org
> Cc: iommu@lists.linux.dev
> Reviewed-by: Pranjal Shrivastava <praan@google.com>
> Signed-off-by: David Hu <xuehaohu@google.com>

Reviewed-by: Kevin Tian <kevin.tian@intel.com>

Claude review: dma-buf: Fix silent overflow for phys vec to sgt

[Claude Code Review Bot]

Overall Series Review

Subject: dma-buf: Fix silent overflow for phys vec to sgt
Author: David Hu <xuehaohu@google.com>
Patches: 2
Reviewed: 2026-06-04T13:39:51.634825

---

This is a single-patch fix for a real silent integer overflow bug in the dma-buf MMIO-to-scatterlist mapping path. When MMIO regions exceed 4GB and P2P DMA goes through the host bridge, `mapped_len` (previously `unsigned int`) wraps around when accumulating `size_t` lengths, causing truncated values to be passed to `dma_iova_sync()` and `fill_sg_entry()`. The fix is minimal, well-targeted, and at v5 has addressed all prior reviewer feedback. The patch looks correct and ready to merge.

**Verdict: Looks good. No blocking issues.**

---
Generated by Claude Code Patch Reviewer

Claude review: dma-buf: Fix silent overflow for phys vec to sgt

[Claude Code Review Bot]

Patch Review

**The core bug fix (mapped_len) — correct:**

```c
-	unsigned int nents, mapped_len = 0;
 	struct dma_buf_dma *dma;
 	struct scatterlist *sgl;
+	size_t mapped_len = 0;
+	unsigned int nents;
```

This is the primary fix. `mapped_len` accumulates `phys_vec[i].len` which is `size_t` (confirmed from `struct phys_vec` in `include/linux/types.h:173`). With a >4GB MMIO region, the old `unsigned int` silently wraps. The downstream consumers `dma_iova_sync()` and `fill_sg_entry()` both take `size_t` length parameters, so `size_t mapped_len` is the correct type. The variable reordering follows reverse Christmas tree style — good.

**The calc_sg_nents overflow protection — correct:**

```c
-	unsigned int nents = 0;
+	size_t nents = 0;
```

Using `size_t` for the intermediate accumulation is correct. In the non-IOVA path, the loop `nents += DIV_ROUND_UP(phys_vec[i].len, UINT_MAX)` accumulates across `nr_ranges` entries, and theoretically could exceed `UINT_MAX` with enough large ranges. The function still returns `unsigned int`, which matches what `sg_alloc_table()` expects (`unsigned int nents` per `include/linux/scatterlist.h:464`).

```c
+	if (nents > UINT_MAX)
+		return 0;
```

Returning 0 as a sentinel for overflow is a reasonable convention given that 0 nents is never a valid return from this function (it would mean zero-length mapping, which callers shouldn't request).

**The caller-side overflow check — correct:**

```c
 	nents = calc_sg_nents(dma->state, phys_vec, nr_ranges, size);
+	if (!nents) {
+		ret = -EINVAL;
+		goto err_free_state;
+	}
```

The goto target `err_free_state` is correct for this point in the function — `dma->state` may have been allocated by the `PCI_P2PDMA_MAP_THRU_HOST_BRIDGE` path above, and `dma` itself also needs freeing. Both are handled by the `err_free_state` → `err_free_dma` cleanup chain.

**Minor note:** This conflates "overflow" with "legitimately zero nents" under a single `-EINVAL`. In practice, zero nents would only happen if the caller passes `size=0` or `nr_ranges=0`, both of which are caller bugs deserving `-EINVAL` anyway, so no issue.

**The fill_sg_entry type consistency fix — fine:**

```c
-	int i;
+	unsigned int i;
```

This matches `i` to the type of `nents` (`unsigned int`), eliminating a signed/unsigned comparison in `i < nents`. Not a practical bug (nents here is computed from a single range's length, so always small), but it's the right type and silences compiler warnings.

**Commit message:** Clear and accurate. The Fixes tag references the correct introducing commit. The Cc: stable is appropriate for a data corruption bug. The changelog across v2-v5 shows responsive iteration to reviewer feedback.

**No issues found. Reviewed-by quality.**

---
Generated by Claude Code Patch Reviewer