linux.git/drivers/accel/amdxdna, branch v7.2

accel/amdxdna: Skip unmapped range in aie2_populate_range()

2026-08-13T06:12:20+00:00

aie2_populate_range() incorrectly failed jobs for BOs with multiple
mmaps: if the unmapped entry appeared first in umap_list, the loop would
pick it up, call hmm_range_fault() on a gone VMA, and return -EFAULT
without ever trying the remaining valid mapps.

Fix it by skipping unmapped entries. After the loop, if the map list is
empty or all maps are valid, map_invalid can be cleared normally.

Fixes: e486147c912f ("accel/amdxdna: Add BO import and export")
Reviewed-by: Max Zhen 
Signed-off-by: Lizhi Hou 
Link: https://patch.msgid.link/20260812205628.810816-1-lizhi.hou@amd.com

Revert "accel/amdxdna: Remove drm_sched_init_args->num_rqs usage"

2026-08-11T16:34:06+00:00

This reverts commit ac58121339db0178186d256a956bb65feb8b6e45.

Signed-off-by: Tvrtko Ursulin 
Cc: Luke.Wildhardt@proton.me
Cc: Matthew Brost 
Cc: Danilo Krummrich 
Cc: Philipp Stanner 
Cc: Christian König 
Signed-off-by: Tvrtko Ursulin 
Link: https://lore.kernel.org/r/20260811163139.99746-16-tvrtko.ursulin@igalia.com

accel/amdxdna: Fix locally exploitable BUG_ON in amdxdna_insert_pages()

2026-08-01T05:40:29+00:00

In amdxdna_insert_pages(), vm_flags_mod() sets VM_MIXEDMAP and clears
VM_PFNMAP. If an unprivileged userspace process mmaps a non-imported GEM
object and then calls madvise(MADV_DONTNEED), the PTEs will be
successfully cleared because VM_MIXEDMAP allows this (unlike VM_PFNMAP).

When userspace subsequently accesses the memory, drm_gem_shmem_fault()
handles the page fault and attempts to map the backing shmem page via
vmf_insert_pfn() which calls vmf_insert_pfn_prot(). Because the backing
shmem page is normal system memory (pfn_valid(pfn) is true) and the VMA
now has VM_MIXEDMAP set, won't this predictably trigger the explicit
assertion BUG_ON((vma->vm_flags & VM_MIXEDMAP) && pfn_valid(pfn))

Fix by removing the vm_flags_mod() call and replacing the vm_insert_pages()
pre-population with the handle_mm_fault() loop that was already used for
the import (dma-buf) path.

Fixes: e486147c912f ("accel/amdxdna: Add BO import and export")
Reviewed-by: Max Zhen 
Signed-off-by: Lizhi Hou 
Link: https://patch.msgid.link/20260731185955.3449311-1-lizhi.hou@amd.com

accel/amxdna: Fix page-insertion errors in amdxdna_insert_pages()

2026-07-31T18:09:19+00:00

Two error paths in amdxdna_insert_pages() called vma->vm_ops->close(vma)
before returning an error code to the caller.  This is incorrect:
amdxdna_gem_obj_mmap() registers an HMM interval notifier before calling
amdxdna_insert_pages(), and on a hard error it jumps to hmm_unreg to undo
that registration.  Calling vm_ops->close() manually — which drops the
shmem pages_pin_count and the GEM object reference that backs the VMA —
before the mmap syscall has even returned causes those resources to be
released while the VMA is still alive.  The kernel VMA teardown will call
vm_ops->close() a second time when the process later unmaps the range,
producing a reference count underflow.

Replace both hard-error returns with a deferred-fault approach that keeps
the VMA alive and retries page insertion through the HMM range-fault path.

Fixes: e486147c912f ("accel/amdxdna: Add BO import and export")
Reviewed-by: Max Zhen 
Signed-off-by: Lizhi Hou 
Link: https://patch.msgid.link/20260723074256.2435143-1-lizhi.hou@amd.com

accel/amdxdna: Fix command timeout race

2026-07-20T01:23:40+00:00

When two commands enter aie2_sched_job_timedout() concurrently, both
check the timeout detection state. The first scheduler thread observes
tdr_status as SIGNALED and updates it to WAIT. The second thread then
observes the updated state instead of the original SIGNALED state, which
may cause the command timeout to be handled incorrectly.

Replace tdr_status with last_signal_ts, which records the timestamp of
the last driver signal. Timeout detection now only reads
last_signal_ts and never modifies it, allowing multiple serialized
detect() calls under dev_lock to evaluate the same signal timestamp
independently. If there is not any new job scheduled or completed
within tdr_timeout_ms, the command will timeout.

Fixes: 9022f010977f ("accel/amdxdna: Check for device hang on job timeout")
Signed-off-by: Wendy Liang 
Reviewed-by: Max Zhen 
Signed-off-by: Lizhi Hou 
Link: https://patch.msgid.link/20260718083409.1825940-1-lizhi.hou@amd.com

accel/amdxdna: Fix use-after-free of mm_struct in job scheduler

2026-07-17T03:05:28+00:00

amdxdna_cmd_submit() stores current->mm in job->mm without holding any
reference. aie2_sched_job_run() later access job->mm from the DRM
scheduler worker thread. With only a raw pointer and no structural
reference, the mm_struct can be freed before the scheduler runs the job.

Fix this by calling mmgrab() to hold a structural mm_count reference for
the lifetime of the job, paired with mmdrop() in every cleanup path.

Fixes: aac243092b70 ("accel/amdxdna: Add command execution")
Reviewed-by: Max Zhen 
Signed-off-by: Lizhi Hou 
Link: https://patch.msgid.link/20260716151305.1595780-1-lizhi.hou@amd.com

accel/amdxdna: reject command submission on devices without a submit op

2026-07-15T01:09:08+00:00

amdxdna_cmd_submit() calls xdna->dev_info->ops->cmd_submit()
unconditionally, but only aie2_dev_ops defines that callback.
aie4_vf_ops (the AIE4 SR-IOV virtual function) does not, so a user
AMDXDNA_EXEC_CMD ioctl on an AIE4 device reaches a NULL function-pointer
call and oopses the kernel. AIE4 submits work through a mapped user queue
and doorbell, not this ioctl path.

Reject the submission early with -EOPNOTSUPP when the device provides no
cmd_submit op, so the shared EXEC ioctl is a clean no-op on such devices.

Fixes: aac243092b70 ("accel/amdxdna: Add command execution")
Cc: stable@vger.kernel.org
Found by 0sec automated security-research tooling (https://0sec.ai).
Assisted-by: 0sec:claude-opus-4-8
Signed-off-by: Doruk Tan Ozturk 
Reviewed-by: Lizhi Hou 
Signed-off-by: Lizhi Hou 
Link: https://patch.msgid.link/20260713173030.87541-3-doruk@0sec.ai

accel/amdxdna: reject user command submission without a command BO

2026-07-15T01:08:40+00:00

amdxdna_drm_submit_execbuf() passes the user-supplied command BO handle
straight into amdxdna_cmd_submit() with drv_cmd == NULL. When the handle
is AMDXDNA_INVALID_BO_HANDLE (0), the block that fetches job->cmd_bo is
skipped, leaving it NULL, and no check rejects it on the user path (the
!job->cmd_bo guard lives inside the != INVALID branch).

The job is then armed and pushed to the DRM scheduler.
aie2_sched_job_run() takes the drv_cmd == NULL path and calls
amdxdna_cmd_set_state(job->cmd_bo) -> amdxdna_gem_vmap(NULL) ->
to_gobj(NULL)->dev, a NULL pointer dereference in the drm_sched worker.
A process with access to the accel node on a system with a probed AMD NPU
can trigger a kernel oops with a single AMDXDNA_EXEC_CMD ioctl
(cmd_handles = 0).

Only internal driver commands (SYNC_DEBUG_BO / ATTACH_DEBUG_BO)
legitimately pass AMDXDNA_INVALID_BO_HANDLE, and they always set drv_cmd.
Reject the invalid handle for user submissions (drv_cmd == NULL) at the
submit choke point so every user path is covered.

Fixes: aac243092b70 ("accel/amdxdna: Add command execution")
Cc: stable@vger.kernel.org
Found by 0sec automated security-research tooling (https://0sec.ai).
Assisted-by: 0sec:claude-opus-4-8
Signed-off-by: Doruk Tan Ozturk 
Reviewed-by: Lizhi Hou 
Signed-off-by: Lizhi Hou 
Link: https://patch.msgid.link/20260713173030.87541-2-doruk@0sec.ai

accel/amdxdna: Fix potential NULL pointer dereference of abo->client

2026-07-08T03:49:28+00:00

Closing a BO handle clears abo->client, while the underlying GEM object
may remain alive due to internal kernel references. As a result, code
executed after the BO handle is closed may dereference a NULL abo->client
pointer.

Remove accesses to abo->client from code paths that may execute after the
BO handle has been closed.

Fixes: d76856beb4a4 ("accel/amdxdna: Refactor GEM BO handling and add helper APIs for address retrieval")
Reviewed-by: Max Zhen 
Signed-off-by: Lizhi Hou 
Link: https://patch.msgid.link/20260707201556.562191-1-lizhi.hou@amd.com

accel/amdxdna: Check init_srcu_struct() return value

2026-07-08T03:49:19+00:00

The return value of init_srcu_struct() is currently ignored. If
initialization fails, subsequent use of hwctx_srcu may result in invalid
memory accesses.

Check the return value of init_srcu_struct() and propagate the error to
the caller.

Fixes: aac243092b70 ("accel/amdxdna: Add command execution")
Reviewed-by: Mario Limonciello (AMD) 
Signed-off-by: Lizhi Hou 
Link: https://patch.msgid.link/20260707172323.539721-1-lizhi.hou@amd.com