[PATCH 0/3] drm/amdgpu: three independent fixes in the CS and VM paths

[PATCH 0/3] drm/amdgpu: three independent fixes in the CS and VM paths

[Junrui Luo via B4 Relay]

Three independent fixes; no dependency between them, they can be applied
or dropped individually.

Patch 1 rejects submissions carrying more than one AMDGPU_CHUNK_ID_FENCE
chunk.  p->uf_bo is a single-slot field, so every FENCE chunk but the last
leaks a BO reference that outlives handle close and process exit.

Patch 2 clamps the rounded-up entry count in amdgpu_vm_update_range().
Where AMDGPU_GPU_PAGES_IN_CPU_PAGE is greater than 1, a mapping whose GPU
page count is not a multiple of it can round num_entries up past what the
cursor holds and trip BUG_ON(size > cur->remaining) in amdgpu_res_next().
4K-page hosts are unaffected.

Patch 3 adds the mapping offset when computing the CPU-side pointer to an
IB in amdgpu_cs_patch_ibs().  The page tables are programmed from
mapping->offset, so for a mapping created with a non-zero offset_in_bo the
kernel inspects different bytes than the GPU executes.

Signed-off-by: Junrui Luo <moonafterrain@outlook.com>
---
Junrui Luo (3):
      drm/amdgpu: disallow multiple FENCE chunks in one submit
      drm/amdgpu: fix VM update overrun on non-4K page kernels
      drm/amdgpu: add the BO-va mapping offset when kmapping an IB

 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 6 +++++-
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 5 +++--
 2 files changed, 8 insertions(+), 3 deletions(-)
---
base-commit: 075b74841bd0065a3bda3440873c747938e69b68
change-id: 20260806-amdgpu-fixes-7ce39504b98d

Best regards,
-- 
Junrui Luo <moonafterrain@outlook.com>

[PATCH 0/3] drm/amdgpu: three independent fixes in the CS and VM paths

[Junrui Luo]

Three independent fixes; no dependency between them, they can be applied
or dropped individually.

Patch 1 rejects submissions carrying more than one AMDGPU_CHUNK_ID_FENCE
chunk.  p->uf_bo is a single-slot field, so every FENCE chunk but the last
leaks a BO reference that outlives handle close and process exit.

Patch 2 clamps the rounded-up entry count in amdgpu_vm_update_range().
Where AMDGPU_GPU_PAGES_IN_CPU_PAGE is greater than 1, a mapping whose GPU
page count is not a multiple of it can round num_entries up past what the
cursor holds and trip BUG_ON(size > cur->remaining) in amdgpu_res_next().
4K-page hosts are unaffected.

Patch 3 adds the mapping offset when computing the CPU-side pointer to an
IB in amdgpu_cs_patch_ibs().  The page tables are programmed from
mapping->offset, so for a mapping created with a non-zero offset_in_bo the
kernel inspects different bytes than the GPU executes.

Signed-off-by: Junrui Luo <moonafterrain@outlook.com>
---
Junrui Luo (3):
      drm/amdgpu: disallow multiple FENCE chunks in one submit
      drm/amdgpu: fix VM update overrun on non-4K page kernels
      drm/amdgpu: add the BO-va mapping offset when kmapping an IB

 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 6 +++++-
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 5 +++--
 2 files changed, 8 insertions(+), 3 deletions(-)
---
base-commit: 075b74841bd0065a3bda3440873c747938e69b68
change-id: 20260806-amdgpu-fixes-7ce39504b98d

Best regards,
-- 
Junrui Luo <moonafterrain@outlook.com>

[PATCH 1/3] drm/amdgpu: disallow multiple FENCE chunks in one submit

[Junrui Luo via B4 Relay]

From: Junrui Luo <moonafterrain@outlook.com>

amdgpu_cs_pass1() dispatches on chunk_id once per chunk without
rejecting repeated ids. p->uf_bo is a single-slot field, so a
submission carrying two AMDGPU_CHUNK_ID_FENCE chunks runs
amdgpu_cs_p1_user_fence() twice, and the second run overwrites
p->uf_bo with a freshly referenced BO without dropping the reference
taken by the first.

amdgpu_cs_parser_fini() only unrefs the final p->uf_bo, so every FENCE
chunk but the last leaks a BO reference. The leaked BO outlives handle
close and process exit.

Reject duplicate FENCE chunks the same way commit fec5f8e8c6bc
("drm/amdgpu: disallow multiple BO_HANDLES chunks in one submit") did
for p->bo_list.

Fixes: d38ceaf99ed0 ("drm/amdgpu: add core driver (v4)")
Reported-by: Yuhao Jiang <danisjiang@gmail.com>
Assisted-by: Claude:claude-opus-5
Cc: stable@vger.kernel.org
Signed-off-by: Junrui Luo <moonafterrain@outlook.com>
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index 5445f75741b5..9c514cb01096 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -228,6 +228,10 @@ static int amdgpu_cs_pass1(struct amdgpu_cs_parser *p,
 			if (size < sizeof(struct drm_amdgpu_cs_chunk_fence))
 				goto free_partial_kdata;
 
+			/* Only a single user fence is allowed to simplify handling. */
+			if (p->uf_bo)
+				goto free_partial_kdata;
+
 			ret = amdgpu_cs_p1_user_fence(p, p->chunks[i].kdata,
 						      &uf_offset);
 			if (ret)

-- 
2.51.2

[PATCH 1/3] drm/amdgpu: disallow multiple FENCE chunks in one submit

[Junrui Luo]

amdgpu_cs_pass1() dispatches on chunk_id once per chunk without
rejecting repeated ids. p->uf_bo is a single-slot field, so a
submission carrying two AMDGPU_CHUNK_ID_FENCE chunks runs
amdgpu_cs_p1_user_fence() twice, and the second run overwrites
p->uf_bo with a freshly referenced BO without dropping the reference
taken by the first.

amdgpu_cs_parser_fini() only unrefs the final p->uf_bo, so every FENCE
chunk but the last leaks a BO reference. The leaked BO outlives handle
close and process exit.

Reject duplicate FENCE chunks the same way commit fec5f8e8c6bc
("drm/amdgpu: disallow multiple BO_HANDLES chunks in one submit") did
for p->bo_list.

Fixes: d38ceaf99ed0 ("drm/amdgpu: add core driver (v4)")
Reported-by: Yuhao Jiang <danisjiang@gmail.com>
Assisted-by: Claude:claude-opus-5
Cc: stable@vger.kernel.org
Signed-off-by: Junrui Luo <moonafterrain@outlook.com>
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index 5445f75741b5..9c514cb01096 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -228,6 +228,10 @@ static int amdgpu_cs_pass1(struct amdgpu_cs_parser *p,
 			if (size < sizeof(struct drm_amdgpu_cs_chunk_fence))
 				goto free_partial_kdata;
 
+			/* Only a single user fence is allowed to simplify handling. */
+			if (p->uf_bo)
+				goto free_partial_kdata;
+
 			ret = amdgpu_cs_p1_user_fence(p, p->chunks[i].kdata,
 						      &uf_offset);
 			if (ret)

-- 
2.51.2

[PATCH 2/3] drm/amdgpu: fix VM update overrun on non-4K page kernels

[Junrui Luo via B4 Relay]

From: Junrui Luo <moonafterrain@outlook.com>

The contiguity scan in amdgpu_vm_update_range() rounds num_entries up to
count * AMDGPU_GPU_PAGES_IN_CPU_PAGE, but count is only constrained by
the loop bound when the loop body executes. The guard
num_entries > AMDGPU_GPU_PAGES_IN_CPU_PAGE proves that
tmp = num_entries / AMDGPU_GPU_PAGES_IN_CPU_PAGE is at least 1, while
the initial count of 2 needs tmp >= 2.

Each iteration consumes a multiple of AMDGPU_GPU_PAGES_IN_CPU_PAGE, so a
mapping whose GPU page count is not a multiple of it eventually reaches
an iteration where num_entries is above AMDGPU_GPU_PAGES_IN_CPU_PAGE but
below twice that. tmp is then 1, the loop body never runs, count keeps
its initial value, and num_entries is rounded up past what the cursor
holds, tripping BUG_ON(size > cur->remaining) in amdgpu_res_next().
AMDGPU_GEM_VA is DRM_RENDER_ALLOW and amdgpu_vm_verify_parameters() only
requires map_size to be a multiple of AMDGPU_GPU_PAGE_SIZE, so an
unprivileged caller can reach this. On 4K page hosts
AMDGPU_GPU_PAGES_IN_CPU_PAGE is 1, tmp >= 2 always holds, and the bug is
unreachable.

Clamp the rounded-up value against num_entries, mirroring the min() that
amdgpu_res_first() already applies to cur->size. A contiguous short tail
is then mapped in full, and a non-contiguous one falls back to a single
CPU page so the loop still makes forward progress.

Fixes: a39f2a8d7066 ("drm/amdgpu: nuke amdgpu_vm_bo_split_mapping v2")
Reported-by: Yuhao Jiang <danisjiang@gmail.com>
Assisted-by: Claude:claude-opus-5
Cc: stable@vger.kernel.org
Signed-off-by: Junrui Luo <moonafterrain@outlook.com>
---
Found by code inspection; not tested on hardware. I have no access to a
64K-page host with an AMD GPU, so the BUG_ON() path was not exercised at
runtime.
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index dc6a9d7dd0b2..365a1c4a4527 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -1193,8 +1193,9 @@ int amdgpu_vm_update_range(struct amdgpu_device *adev, struct amdgpu_vm *vm,
 				}
 				if (!contiguous)
 					count--;
-				num_entries = count *
-					AMDGPU_GPU_PAGES_IN_CPU_PAGE;
+				num_entries = min(count *
+						  AMDGPU_GPU_PAGES_IN_CPU_PAGE,
+						  num_entries);
 			}
 
 			if (!contiguous) {

-- 
2.51.2

[PATCH 2/3] drm/amdgpu: fix VM update overrun on non-4K page kernels

[Junrui Luo]

The contiguity scan in amdgpu_vm_update_range() rounds num_entries up to
count * AMDGPU_GPU_PAGES_IN_CPU_PAGE, but count is only constrained by
the loop bound when the loop body executes. The guard
num_entries > AMDGPU_GPU_PAGES_IN_CPU_PAGE proves that
tmp = num_entries / AMDGPU_GPU_PAGES_IN_CPU_PAGE is at least 1, while
the initial count of 2 needs tmp >= 2.

Each iteration consumes a multiple of AMDGPU_GPU_PAGES_IN_CPU_PAGE, so a
mapping whose GPU page count is not a multiple of it eventually reaches
an iteration where num_entries is above AMDGPU_GPU_PAGES_IN_CPU_PAGE but
below twice that. tmp is then 1, the loop body never runs, count keeps
its initial value, and num_entries is rounded up past what the cursor
holds, tripping BUG_ON(size > cur->remaining) in amdgpu_res_next().
AMDGPU_GEM_VA is DRM_RENDER_ALLOW and amdgpu_vm_verify_parameters() only
requires map_size to be a multiple of AMDGPU_GPU_PAGE_SIZE, so an
unprivileged caller can reach this. On 4K page hosts
AMDGPU_GPU_PAGES_IN_CPU_PAGE is 1, tmp >= 2 always holds, and the bug is
unreachable.

Clamp the rounded-up value against num_entries, mirroring the min() that
amdgpu_res_first() already applies to cur->size. A contiguous short tail
is then mapped in full, and a non-contiguous one falls back to a single
CPU page so the loop still makes forward progress.

Fixes: a39f2a8d7066 ("drm/amdgpu: nuke amdgpu_vm_bo_split_mapping v2")
Reported-by: Yuhao Jiang <danisjiang@gmail.com>
Assisted-by: Claude:claude-opus-5
Cc: stable@vger.kernel.org
Signed-off-by: Junrui Luo <moonafterrain@outlook.com>
---
Found by code inspection; not tested on hardware. I have no access to a
64K-page host with an AMD GPU, so the BUG_ON() path was not exercised at
runtime.
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index dc6a9d7dd0b2..365a1c4a4527 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -1193,8 +1193,9 @@ int amdgpu_vm_update_range(struct amdgpu_device *adev, struct amdgpu_vm *vm,
 				}
 				if (!contiguous)
 					count--;
-				num_entries = count *
-					AMDGPU_GPU_PAGES_IN_CPU_PAGE;
+				num_entries = min(count *
+						  AMDGPU_GPU_PAGES_IN_CPU_PAGE,
+						  num_entries);
 			}
 
 			if (!contiguous) {

-- 
2.51.2

[PATCH 3/3] drm/amdgpu: add the BO-va mapping offset when kmapping an IB

[Junrui Luo via B4 Relay]

From: Junrui Luo <moonafterrain@outlook.com>

amdgpu_cs_patch_ibs() derives the CPU-side view of a UVD/VCE/VCN
indirect buffer from the BO returned by amdgpu_cs_find_mapping():

    r = amdgpu_bo_kmap(aobj, (void **)&kptr);
    kptr += va_start - (m->start * AMDGPU_GPU_PAGE_SIZE);

amdgpu_bo_kmap() returns the start of the BO, so only the displacement
of va_start inside the mapping is added.  The page tables, however, are
programmed from mapping->offset (see amdgpu_vm_bo_update()), which
records the offset_in_bo the client passed to AMDGPU_GEM_VA.  The GPU
therefore resolves va_start to BO byte

    m->offset + (va_start - m->start * AMDGPU_GPU_PAGE_SIZE)

while the kernel inspects the byte m->offset lower.  Whenever an IB is
submitted through a mapping created with a non-zero offset_in_bo, the
two views disagree.

Add the missing term so the kmapped pointer describes the same bytes the
page tables do.

Every other CPU-side consumer of amdgpu_cs_find_mapping() omits
mapping->offset in the same way.

Fixes: 4802ce117786 ("drm/amdgpu: fix UVD/VCE VM emulation")
Reported-by: Yuhao Jiang <danisjiang@gmail.com>
Assisted-by: Claude:claude-opus-5
Signed-off-by: Junrui Luo <moonafterrain@outlook.com>
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index 9c514cb01096..a72cee871af3 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -1047,7 +1047,7 @@ static int amdgpu_cs_patch_ibs(struct amdgpu_cs_parser *p,
 		if (r)
 			return r;
 
-		kptr += va_start - (m->start * AMDGPU_GPU_PAGE_SIZE);
+		kptr += m->offset + va_start - (m->start * AMDGPU_GPU_PAGE_SIZE);
 
 		if (ring->funcs->parse_cs) {
 			memcpy(ib->ptr, kptr, ib->length_dw * 4);

-- 
2.51.2

[PATCH 3/3] drm/amdgpu: add the BO-va mapping offset when kmapping an IB

[Junrui Luo]

amdgpu_cs_patch_ibs() derives the CPU-side view of a UVD/VCE/VCN
indirect buffer from the BO returned by amdgpu_cs_find_mapping():

    r = amdgpu_bo_kmap(aobj, (void **)&kptr);
    kptr += va_start - (m->start * AMDGPU_GPU_PAGE_SIZE);

amdgpu_bo_kmap() returns the start of the BO, so only the displacement
of va_start inside the mapping is added.  The page tables, however, are
programmed from mapping->offset (see amdgpu_vm_bo_update()), which
records the offset_in_bo the client passed to AMDGPU_GEM_VA.  The GPU
therefore resolves va_start to BO byte

    m->offset + (va_start - m->start * AMDGPU_GPU_PAGE_SIZE)

while the kernel inspects the byte m->offset lower.  Whenever an IB is
submitted through a mapping created with a non-zero offset_in_bo, the
two views disagree.

Add the missing term so the kmapped pointer describes the same bytes the
page tables do.

Every other CPU-side consumer of amdgpu_cs_find_mapping() omits
mapping->offset in the same way.

Fixes: 4802ce117786 ("drm/amdgpu: fix UVD/VCE VM emulation")
Reported-by: Yuhao Jiang <danisjiang@gmail.com>
Assisted-by: Claude:claude-opus-5
Signed-off-by: Junrui Luo <moonafterrain@outlook.com>
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index 9c514cb01096..a72cee871af3 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -1047,7 +1047,7 @@ static int amdgpu_cs_patch_ibs(struct amdgpu_cs_parser *p,
 		if (r)
 			return r;
 
-		kptr += va_start - (m->start * AMDGPU_GPU_PAGE_SIZE);
+		kptr += m->offset + va_start - (m->start * AMDGPU_GPU_PAGE_SIZE);
 
 		if (ring->funcs->parse_cs) {
 			memcpy(ib->ptr, kptr, ib->length_dw * 4);

-- 
2.51.2

Re: [PATCH 2/3] drm/amdgpu: fix VM update overrun on non-4K page kernels

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

Pre-existing issues:
- [Critical] Unhandled error path leaks BOs and leaves dangling pointers to a stack-allocated list, leading to stack corruption.
- [High] Sub-page offset is dropped when mapping contiguous system memory on non-4K page kernels, causing data corruption.
--

--- Patch [2]: [PATCH 2/3] drm/amdgpu: fix VM update overrun on non-4K page kernels ---
commit 250ebbca695a7882625e4e4f1a9f6af7c33fde76
Author: Junrui Luo <moonafterrain@outlook.com>
drm/amdgpu: fix VM update overrun on non-4K page kernels

This commit fixes a VM update overrun bug in amdgpu_vm_update_range() on
systems where the CPU page size is larger than the GPU page size. It clamps
num_entries against the rounded-up value during the contiguity scan. This
prevents an issue where an unprivileged caller could trigger a BUG_ON by
mapping memory with a non-multiple GPU page count.

> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> index dc6a9d7dd0b28..365a1c4a45275 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> @@ -1193,8 +1193,9 @@ int amdgpu_vm_update_range(struct amdgpu_device *adev, struct amdgpu_vm *vm,
>  				}
>  				if (!contiguous)
>  					count--;
> -				num_entries = count *
> -					AMDGPU_GPU_PAGES_IN_CPU_PAGE;
> +				num_entries = min(count *
> +						  AMDGPU_GPU_PAGES_IN_CPU_PAGE,
> +						  num_entries);
>  			}
>  
>  			if (!contiguous) {

[Severity: High]
This is a pre-existing issue, but does this code drop the sub-page offset
when mapping contiguous memory?

In amdgpu_vm_update_range(), if a user maps system memory where
PAGE_SIZE > AMDGPU_GPU_PAGE_SIZE at a sub-CPU-page offset and the pages are
physically contiguous, addr is set to pages_addr[cursor.start >> PAGE_SHIFT].

Because params.pages_addr is set to NULL, the sub-page offset
(cursor.start & ~PAGE_MASK) is dropped. Could this cause the GPU to map
memory starting from the beginning of the CPU page instead of the requested
offset, returning incorrect data to the user?

[Severity: Critical]
This is a pre-existing issue, but does the error_free path in this function
leave dangling pointers to the stack-allocated params.tlb_flush_waitlist?

During amdgpu_vm_ptes_update() later in this loop, replaced page table
entries are added to params.tlb_flush_waitlist, which is allocated on the
stack in amdgpu_vm_update_range().

If a subsequent operation fails, the code jumps to error_free:

		r = amdgpu_vm_ptes_update(&params, start, tmp, addr, flags);
		if (r)
			goto error_free;

This bypasses the call to amdgpu_vm_pt_free_list() which would normally
process and free the list.

When the function returns, its stack frame is reclaimed, but the
amdgpu_vm_bo_base entries in the software tree still have their vm_status
list nodes pointing to this reclaimed stack memory.

When the VM is later destroyed, amdgpu_vm_pt_free_root() traverses the tree
and calls list_del() on these entries. Could this write to the dangling stack
pointers and cause arbitrary stack corruption?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260806-amdgpu-fixes-v1-0-ce247012d4da@outlook.com?part=2

Re: [PATCH 3/3] drm/amdgpu: add the BO-va mapping offset when kmapping an IB

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Incomplete bug fix: multiple CPU-side consumers of `amdgpu_cs_find_mapping()` ignore `mapping->offset`, causing validation bypasses and incorrect hardware programming.
--

--- Patch [3]: [PATCH 3/3] drm/amdgpu: add the BO-va mapping offset when kmapping an IB ---
commit d8bdec727584870cf6250f253ea262e5bbf96aef
Author: Junrui Luo <moonafterrain@outlook.com>

drm/amdgpu: add the BO-va mapping offset when kmapping an IB

This patch fixes the CPU-side view of indirect buffers (IBs) in
amdgpu_cs_patch_ibs(). It adds the missing mapping offset to the kmapped
pointer so it accurately reflects the bytes programmed into the page tables.

> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> index 9c514cb010966..a72cee871af3d 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> @@ -1047,7 +1047,7 @@ static int amdgpu_cs_patch_ibs(struct amdgpu_cs_parser *p,
>  		if (r)
>  			return r;
>  
> -		kptr += va_start - (m->start * AMDGPU_GPU_PAGE_SIZE);
> +		kptr += m->offset + va_start - (m->start * AMDGPU_GPU_PAGE_SIZE);

[Severity: High]
This is a pre-existing issue, but while this patch fixes the mapping offset
calculation here, do we need to apply the same fix to other CPU-side consumers
of amdgpu_cs_find_mapping()?

The commit message notes that every other CPU-side consumer omits
mapping->offset in the same way. Does this mean they are still vulnerable to
incorrect hardware programming or validation bypasses?

For example, when calculating the physical GPU address to patch into the UVD
IB, amdgpu_uvd_cs_pass2() in drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c does not
include mapping->offset:

	addr -= mapping->start * AMDGPU_GPU_PAGE_SIZE;
	start += addr;

Similar calculations omitting mapping->offset occur in:
- drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c:amdgpu_vce_cs_reloc()
- drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c:vcn_v3_0_dec_msg()
- drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c:vcn_v4_0_dec_msg()
- drivers/gpu/drm/amd/amdgpu/amdgpu_dev_coredump.c:amdgpu_dev_coredump_print_ibs()
- drivers/gpu/drm/amd/amdgpu/amdgpu_userq_fence.c:amdgpu_userq_fence_read_wptr()

If a user submits a command stream with an IB mapped with a non-zero
offset_in_bo, could this lead to hardware hangs by bypassing VCN codec
validation, or corrupt UVD/VCE command stream physical address patching?

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260806-amdgpu-fixes-v1-0-ce247012d4da@outlook.com?part=3

Re: [PATCH 1/3] drm/amdgpu: disallow multiple FENCE chunks in one submit

[Christian König]

On 8/6/26 06:45, Junrui Luo via B4 Relay wrote:
> amdgpu_cs_pass1() dispatches on chunk_id once per chunk without
> rejecting repeated ids. p->uf_bo is a single-slot field, so a
> submission carrying two AMDGPU_CHUNK_ID_FENCE chunks runs
> amdgpu_cs_p1_user_fence() twice, and the second run overwrites
> p->uf_bo with a freshly referenced BO without dropping the reference
> taken by the first.
> 
> amdgpu_cs_parser_fini() only unrefs the final p->uf_bo, so every FENCE
> chunk but the last leaks a BO reference. The leaked BO outlives handle
> close and process exit.
> 
> Reject duplicate FENCE chunks the same way commit fec5f8e8c6bc
> ("drm/amdgpu: disallow multiple BO_HANDLES chunks in one submit") did
> for p->bo_list.
> 
> Fixes: d38ceaf99ed0 ("drm/amdgpu: add core driver (v4)")
> Reported-by: Yuhao Jiang <danisjiang@gmail.com>
> Assisted-by: Claude:claude-opus-5
> Cc: stable@vger.kernel.org
> Signed-off-by: Junrui Luo <moonafterrain@outlook.com>

Reviewed-by: Christian König <christian.koenig@amd.com>

Thanks,
Christian.

> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> index 5445f75741b5..9c514cb01096 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> @@ -228,6 +228,10 @@ static int amdgpu_cs_pass1(struct amdgpu_cs_parser *p,
>                         if (size < sizeof(struct drm_amdgpu_cs_chunk_fence))
>                                 goto free_partial_kdata;
> 
> +                       /* Only a single user fence is allowed to simplify handling. */
> +                       if (p->uf_bo)
> +                               goto free_partial_kdata;
> +
>                         ret = amdgpu_cs_p1_user_fence(p, p->chunks[i].kdata,
>                                                       &uf_offset);
>                         if (ret)
> 
> --
> 2.51.2
> 
> 

Re: [PATCH 2/3] drm/amdgpu: fix VM update overrun on non-4K page kernels

[Christian König]

On 8/6/26 06:45, Junrui Luo via B4 Relay wrote:
> [Some people who received this message don't often get email from devnull+moonafterrain.outlook.com@kernel.org. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
> 
> From: Junrui Luo <moonafterrain@outlook.com>
> 
> The contiguity scan in amdgpu_vm_update_range() rounds num_entries up to
> count * AMDGPU_GPU_PAGES_IN_CPU_PAGE, but count is only constrained by
> the loop bound when the loop body executes. The guard
> num_entries > AMDGPU_GPU_PAGES_IN_CPU_PAGE proves that
> tmp = num_entries / AMDGPU_GPU_PAGES_IN_CPU_PAGE is at least 1, while
> the initial count of 2 needs tmp >= 2.
> 
> Each iteration consumes a multiple of AMDGPU_GPU_PAGES_IN_CPU_PAGE, so a
> mapping whose GPU page count is not a multiple of it eventually reaches
> an iteration where num_entries is above AMDGPU_GPU_PAGES_IN_CPU_PAGE but
> below twice that. tmp is then 1, the loop body never runs, count keeps
> its initial value, and num_entries is rounded up past what the cursor
> holds, tripping BUG_ON(size > cur->remaining) in amdgpu_res_next().
> AMDGPU_GEM_VA is DRM_RENDER_ALLOW and amdgpu_vm_verify_parameters() only
> requires map_size to be a multiple of AMDGPU_GPU_PAGE_SIZE, so an
> unprivileged caller can reach this. On 4K page hosts
> AMDGPU_GPU_PAGES_IN_CPU_PAGE is 1, tmp >= 2 always holds, and the bug is
> unreachable.
> 
> Clamp the rounded-up value against num_entries, mirroring the min() that
> amdgpu_res_first() already applies to cur->size. A contiguous short tail
> is then mapped in full, and a non-contiguous one falls back to a single
> CPU page so the loop still makes forward progress.
> 
> Fixes: a39f2a8d7066 ("drm/amdgpu: nuke amdgpu_vm_bo_split_mapping v2")
> Reported-by: Yuhao Jiang <danisjiang@gmail.com>
> Assisted-by: Claude:claude-opus-5
> Cc: stable@vger.kernel.org
> Signed-off-by: Junrui Luo <moonafterrain@outlook.com>
> ---
> Found by code inspection; not tested on hardware. I have no access to a
> 64K-page host with an AMD GPU, so the BUG_ON() path was not exercised at
> runtime.

That check is clearly not correct. The pages_addr must be fully consumed, otherwise we run into major problems later on.

We could do something like this instead:

if (pages_addr) {
...
	if (WARN_ON(num_entries % AMDGPU_GPU_PAGES_IN_CPU_PAGE))
		return -EINVAL;
...

Regards,
Christian.

> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> index dc6a9d7dd0b2..365a1c4a4527 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> @@ -1193,8 +1193,9 @@ int amdgpu_vm_update_range(struct amdgpu_device *adev, struct amdgpu_vm *vm,
>                                 }
>                                 if (!contiguous)
>                                         count--;
> -                               num_entries = count *
> -                                       AMDGPU_GPU_PAGES_IN_CPU_PAGE;
> +                               num_entries = min(count *
> +                                                 AMDGPU_GPU_PAGES_IN_CPU_PAGE,
> +                                                 num_entries);
>                         }
> 
>                         if (!contiguous) {
> 
> --
> 2.51.2
> 
> 

Re: [PATCH 3/3] drm/amdgpu: add the BO-va mapping offset when kmapping an IB

[Christian König]

On 8/6/26 06:45, Junrui Luo via B4 Relay wrote:
> [Some people who received this message don't often get email from devnull+moonafterrain.outlook.com@kernel.org. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
> 
> From: Junrui Luo <moonafterrain@outlook.com>
> 
> amdgpu_cs_patch_ibs() derives the CPU-side view of a UVD/VCE/VCN
> indirect buffer from the BO returned by amdgpu_cs_find_mapping():
> 
>     r = amdgpu_bo_kmap(aobj, (void **)&kptr);
>     kptr += va_start - (m->start * AMDGPU_GPU_PAGE_SIZE);
> 
> amdgpu_bo_kmap() returns the start of the BO, so only the displacement
> of va_start inside the mapping is added.  The page tables, however, are
> programmed from mapping->offset (see amdgpu_vm_bo_update()), which
> records the offset_in_bo the client passed to AMDGPU_GEM_VA.  The GPU
> therefore resolves va_start to BO byte
> 
>     m->offset + (va_start - m->start * AMDGPU_GPU_PAGE_SIZE)
> 
> while the kernel inspects the byte m->offset lower.  Whenever an IB is
> submitted through a mapping created with a non-zero offset_in_bo, the
> two views disagree.
> 
> Add the missing term so the kmapped pointer describes the same bytes the
> page tables do.
> 
> Every other CPU-side consumer of amdgpu_cs_find_mapping() omits
> mapping->offset in the same way.
> 
> Fixes: 4802ce117786 ("drm/amdgpu: fix UVD/VCE VM emulation")

Good catch, but completely irrelevant in practice, so just drop that here.

> Reported-by: Yuhao Jiang <danisjiang@gmail.com>
> Assisted-by: Claude:claude-opus-5
> Signed-off-by: Junrui Luo <moonafterrain@outlook.com>

With that done Reviewed-by: Christian König <christian.koenig@amd.com>

Regards,
Christian.

> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> index 9c514cb01096..a72cee871af3 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> @@ -1047,7 +1047,7 @@ static int amdgpu_cs_patch_ibs(struct amdgpu_cs_parser *p,
>                 if (r)
>                         return r;
> 
> -               kptr += va_start - (m->start * AMDGPU_GPU_PAGE_SIZE);
> +               kptr += m->offset + va_start - (m->start * AMDGPU_GPU_PAGE_SIZE);
> 
>                 if (ring->funcs->parse_cs) {
>                         memcpy(ib->ptr, kptr, ib->length_dw * 4);
> 
> --
> 2.51.2
> 
> 

Re: [PATCH 1/3] drm/amdgpu: disallow multiple FENCE chunks in one submit

[Alex Deucher]

Applied.  Thanks!

On Thu, Aug 6, 2026 at 8:03 AM Christian König <christian.koenig@amd.com> wrote:
>
> On 8/6/26 06:45, Junrui Luo via B4 Relay wrote:
> > amdgpu_cs_pass1() dispatches on chunk_id once per chunk without
> > rejecting repeated ids. p->uf_bo is a single-slot field, so a
> > submission carrying two AMDGPU_CHUNK_ID_FENCE chunks runs
> > amdgpu_cs_p1_user_fence() twice, and the second run overwrites
> > p->uf_bo with a freshly referenced BO without dropping the reference
> > taken by the first.
> >
> > amdgpu_cs_parser_fini() only unrefs the final p->uf_bo, so every FENCE
> > chunk but the last leaks a BO reference. The leaked BO outlives handle
> > close and process exit.
> >
> > Reject duplicate FENCE chunks the same way commit fec5f8e8c6bc
> > ("drm/amdgpu: disallow multiple BO_HANDLES chunks in one submit") did
> > for p->bo_list.
> >
> > Fixes: d38ceaf99ed0 ("drm/amdgpu: add core driver (v4)")
> > Reported-by: Yuhao Jiang <danisjiang@gmail.com>
> > Assisted-by: Claude:claude-opus-5
> > Cc: stable@vger.kernel.org
> > Signed-off-by: Junrui Luo <moonafterrain@outlook.com>
>
> Reviewed-by: Christian König <christian.koenig@amd.com>
>
> Thanks,
> Christian.
>
> > ---
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 4 ++++
> >  1 file changed, 4 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> > index 5445f75741b5..9c514cb01096 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> > @@ -228,6 +228,10 @@ static int amdgpu_cs_pass1(struct amdgpu_cs_parser *p,
> >                         if (size < sizeof(struct drm_amdgpu_cs_chunk_fence))
> >                                 goto free_partial_kdata;
> >
> > +                       /* Only a single user fence is allowed to simplify handling. */
> > +                       if (p->uf_bo)
> > +                               goto free_partial_kdata;
> > +
> >                         ret = amdgpu_cs_p1_user_fence(p, p->chunks[i].kdata,
> >                                                       &uf_offset);
> >                         if (ret)
> >
> > --
> > 2.51.2
> >
> >
>

Re: [PATCH 2/3] drm/amdgpu: fix VM update overrun on non-4K page kernels

[Junrui Luo]

On Thu, Aug 06, 2026 at 01:59:52PM +0200, Christian König wrote:
> 
> That check is clearly not correct. The pages_addr must be fully consumed, otherwise we run into major problems later on.

Is that an invariant today?  num_entries <= AMDGPU_GPU_PAGES_IN_CPU_PAGE
skips the scan and is used as it is, so on a 64K page kernel a 4K mapping
maps a single GPU page and pages_addr is not consumed in whole CPU pages
there either.

So what should the code do for a mapping whose size is not a multiple of
AMDGPU_GPU_PAGES_IN_CPU_PAGE?  Could you sketch what you have in mind?

Thanks,
Junrui Luo

Re: [PATCH 2/3] drm/amdgpu: fix VM update overrun on non-4K page kernels

[Christian König]

On 8/8/26 19:03, Junrui Luo wrote:
> On Thu, Aug 06, 2026 at 01:59:52PM +0200, Christian König wrote:
>>
>> That check is clearly not correct. The pages_addr must be fully consumed, otherwise we run into major problems later on.
> 
> Is that an invariant today?  num_entries <= AMDGPU_GPU_PAGES_IN_CPU_PAGE
> skips the scan and is used as it is, so on a 64K page kernel a 4K mapping
> maps a single GPU page and pages_addr is not consumed in whole CPU pages
> there either.

Exactly that doesn't work. On a 64K page kernel mappings *must* be 64K as well.

> So what should the code do for a mapping whose size is not a multiple of
> AMDGPU_GPU_PAGES_IN_CPU_PAGE?  Could you sketch what you have in mind?

That case simply can't happen for user space allocations in the first place.

Regards,
Christian.

> 
> Thanks,
> Junrui Luo