[PATCH 0/2] accel/amdxdna: fix two NULL-deref DoS paths reachable via AMDXDNA_EXEC_CMD

[PATCH 0/2] accel/amdxdna: fix two NULL-deref DoS paths reachable via AMDXDNA_EXEC_CMD

[Doruk Tan Ozturk]

An unprivileged process with access to an AMD NPU accel node can oops the
kernel with a single AMDXDNA_EXEC_CMD ioctl. Two distinct NULL dereferences
are reachable on the command-submit path, both since the driver first gained
command execution:

  1. cmd_handles = 0 (AMDXDNA_INVALID_BO_HANDLE) leaves job->cmd_bo NULL,
     dereferenced later by the DRM scheduler.
  2. On an AIE4 device (no .cmd_submit op) the ioctl calls a NULL function
     pointer.

Both are availability-only (local DoS), no memory corruption. Found by static
analysis; verified against source, not runtime-reproduced (no NPU on hand).


Doruk Tan Ozturk (2):
  accel/amdxdna: reject user command submission without a command BO
  accel/amdxdna: reject command submission on devices without a submit
    op

 drivers/accel/amdxdna/amdxdna_ctx.c | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

-- 
2.43.0

[PATCH 1/2] accel/amdxdna: reject user command submission without a command BO

[Doruk Tan Ozturk]

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 <doruk@0sec.ai>
---
 drivers/accel/amdxdna/amdxdna_ctx.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/accel/amdxdna/amdxdna_ctx.c b/drivers/accel/amdxdna/amdxdna_ctx.c
index 8f8df9d04ec5..a5c8c2c4de6d 100644
--- a/drivers/accel/amdxdna/amdxdna_ctx.c
+++ b/drivers/accel/amdxdna/amdxdna_ctx.c
@@ -603,6 +603,16 @@ int amdxdna_cmd_submit(struct amdxdna_client *client,
 			ret = -EINVAL;
 			goto free_job;
 		}
+	} else if (!drv_cmd) {
+		/*
+		 * Only internal driver commands (drv_cmd != NULL) may omit a
+		 * command BO. A user command submission with the invalid handle
+		 * would leave job->cmd_bo NULL and later fault when the scheduler
+		 * dereferences it in amdxdna_cmd_set_state().
+		 */
+		XDNA_DBG(xdna, "Command BO handle required for user submission");
+		ret = -EINVAL;
+		goto free_job;
 	}
 
 	ret = amdxdna_arg_bos_lookup(client, job, arg_bo_hdls, arg_bo_cnt);
-- 
2.43.0

Re: [PATCH 1/2] accel/amdxdna: reject user command submission without a command BO

[sashiko-bot]

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

Pre-existing issues:
- [High] The current task's `mm_struct` is assigned to `job->mm` without taking a reference count. If the submitting process exits before the DRM scheduler asynchronously executes the job, `job->mm` will point to a freed `mm_struct`, leading to a use-after-free when the scheduler thread accesses it via `mmget_not_zero()`.
--

--- Patch [1]: [PATCH 1/2] accel/amdxdna: reject user command submission without a command BO ---
commit 66fd358bad7187572b37789ea6dae38b8738ff00
Author: Doruk Tan Ozturk <doruk@0sec.ai>

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

This commit adds a check in amdxdna_cmd_submit() to ensure user command
submissions have a valid command BO handle. It rejects invalid handles
early to prevent a NULL pointer dereference in the drm_sched worker.

> diff --git a/drivers/accel/amdxdna/amdxdna_ctx.c b/drivers/accel/amdxdna/amdxdna_ctx.c
> index 8f8df9d04ec56..a5c8c2c4de6d9 100644
> --- a/drivers/accel/amdxdna/amdxdna_ctx.c
> +++ b/drivers/accel/amdxdna/amdxdna_ctx.c
> @@ -603,6 +603,16 @@ int amdxdna_cmd_submit(struct amdxdna_client *client,
>  			ret = -EINVAL;
>  			goto free_job;
>  		}
> +	} else if (!drv_cmd) {
> +		/*
> +		 * Only internal driver commands (drv_cmd != NULL) may omit a
> +		 * command BO. A user command submission with the invalid handle
> +		 * would leave job->cmd_bo NULL and later fault when the scheduler
> +		 * dereferences it in amdxdna_cmd_set_state().
> +		 */
> +		XDNA_DBG(xdna, "Command BO handle required for user submission");
> +		ret = -EINVAL;
> +		goto free_job;
>  	}
>  
>  	ret = amdxdna_arg_bos_lookup(client, job, arg_bo_hdls, arg_bo_cnt);

[ ... ]

> 	job->hwctx = hwctx;
> 	job->mm = current->mm;

[Severity: High]
This is a pre-existing issue, but is it possible for job->mm to become a
dangling pointer if the submitting process exits before the DRM scheduler
asynchronously executes the job?

The current task's mm_struct is assigned to job->mm without taking a reference
via mmgrab(). If a process opens the DRM file descriptor, shares it with a child
process that submits a command and then immediately exits, the parent keeping
the file descriptor open prevents the file's release callback from flushing
pending jobs.

When the DRM scheduler asynchronously picks up the child's job in
aie2_sched_job_run(), it calls mmget_not_zero(job->mm) on the freed mm_struct:

drivers/accel/amdxdna/aie2_ctx.c:aie2_sched_job_run() {
    ...
    if (!mmget_not_zero(job->mm))
        return ERR_PTR(-ESRCH);
    ...
}

Would it be better to pin the mm_struct when assigning it to the job to prevent
a use-after-free?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260713173030.87541-1-doruk@0sec.ai?part=1

Re: [PATCH 1/2] accel/amdxdna: reject user command submission without a command BO

[Lizhi Hou]

On 7/13/26 10:30, Doruk Tan Ozturk wrote:
> 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 <doruk@0sec.ai>
> ---
>   drivers/accel/amdxdna/amdxdna_ctx.c | 10 ++++++++++
>   1 file changed, 10 insertions(+)
>
> diff --git a/drivers/accel/amdxdna/amdxdna_ctx.c b/drivers/accel/amdxdna/amdxdna_ctx.c
> index 8f8df9d04ec5..a5c8c2c4de6d 100644
> --- a/drivers/accel/amdxdna/amdxdna_ctx.c
> +++ b/drivers/accel/amdxdna/amdxdna_ctx.c
> @@ -603,6 +603,16 @@ int amdxdna_cmd_submit(struct amdxdna_client *client,
>   			ret = -EINVAL;
>   			goto free_job;
>   		}
> +	} else if (!drv_cmd) {
> +		/*
> +		 * Only internal driver commands (drv_cmd != NULL) may omit a
> +		 * command BO. A user command submission with the invalid handle
> +		 * would leave job->cmd_bo NULL and later fault when the scheduler
> +		 * dereferences it in amdxdna_cmd_set_state().
> +		 */
> +		XDNA_DBG(xdna, "Command BO handle required for user submission");
> +		ret = -EINVAL;
> +		goto free_job;
Reviewed-by: Lizhi Hou <lizhi.hou@amd.com>
>   	}
>   
>   	ret = amdxdna_arg_bos_lookup(client, job, arg_bo_hdls, arg_bo_cnt);

[PATCH 2/2] accel/amdxdna: reject command submission on devices without a submit op

[Doruk Tan Ozturk]

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 <doruk@0sec.ai>
---
 drivers/accel/amdxdna/amdxdna_ctx.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/accel/amdxdna/amdxdna_ctx.c b/drivers/accel/amdxdna/amdxdna_ctx.c
index a5c8c2c4de6d..bdbd3db12a6c 100644
--- a/drivers/accel/amdxdna/amdxdna_ctx.c
+++ b/drivers/accel/amdxdna/amdxdna_ctx.c
@@ -590,6 +590,10 @@ int amdxdna_cmd_submit(struct amdxdna_client *client,
 	int ret, idx;
 
 	XDNA_DBG(xdna, "Command BO hdl %d, Arg BO count %d", cmd_bo_hdl, arg_bo_cnt);
+
+	if (!xdna->dev_info->ops->cmd_submit)
+		return -EOPNOTSUPP;
+
 	job = kzalloc_flex(*job, bos, arg_bo_cnt);
 	if (!job)
 		return -ENOMEM;
-- 
2.43.0

Re: [PATCH 2/2] accel/amdxdna: reject command submission on devices without a submit op

[Lizhi Hou]

On 7/13/26 10:30, Doruk Tan Ozturk wrote:
> 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 <doruk@0sec.ai>
> ---
>   drivers/accel/amdxdna/amdxdna_ctx.c | 4 ++++
>   1 file changed, 4 insertions(+)
>
> diff --git a/drivers/accel/amdxdna/amdxdna_ctx.c b/drivers/accel/amdxdna/amdxdna_ctx.c
> index a5c8c2c4de6d..bdbd3db12a6c 100644
> --- a/drivers/accel/amdxdna/amdxdna_ctx.c
> +++ b/drivers/accel/amdxdna/amdxdna_ctx.c
> @@ -590,6 +590,10 @@ int amdxdna_cmd_submit(struct amdxdna_client *client,
>   	int ret, idx;
>   
>   	XDNA_DBG(xdna, "Command BO hdl %d, Arg BO count %d", cmd_bo_hdl, arg_bo_cnt);
> +
> +	if (!xdna->dev_info->ops->cmd_submit)
> +		return -EOPNOTSUPP;
> +
Reviewed-by: Lizhi Hou <lizhi.hou@amd.com>
>   	job = kzalloc_flex(*job, bos, arg_bo_cnt);
>   	if (!job)
>   		return -ENOMEM;