From: sashiko-bot@kernel.org
To: "Taimuraz Kaitmazov" <taimuraz@kaitmazov.com>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] accel/amdxdna: check the command payload before using it
Date: Tue, 18 Aug 2026 00:38:27 +0000 [thread overview]
Message-ID: <20260818003828.0CE871F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260818002459.377641-1-taimuraz@kaitmazov.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
Pre-existing issues:
- [Critical] An out-of-bounds write of 4 bytes in `aie2_cmdlist_fill_npu_elf` leads to an integer underflow in `aie2_cmdlist_multi_execbuf`, enabling massive out-of-bounds memory corruption.
- [High] Leaked GEM object reference on error path in amdxdna_cmd_set_error().
--
--- Patch [1]: [PATCH] accel/amdxdna: check the command payload before using it ---
commit ec2f075309e2dcb4167331b4d2cc9a7b02abaa4a
Author: Taimuraz Kaitmazov <taimuraz@kaitmazov.com>
accel/amdxdna: check the command payload before using it
This commit fixes an issue where amdxdna_cmd_get_payload() could return NULL
without setting the size output parameter. Callers in aie2_message.c were using
the uninitialized size for bounds checking and copying from the NULL pointer.
The fix clears the length before an early return and adds checks for the NULL
pointer in callers.
> diff --git a/drivers/accel/amdxdna/aie2_message.c b/drivers/accel/amdxdna/aie2_message.c
> index dfe0fbdf066d2..6f258206d5080 100644
> --- a/drivers/accel/amdxdna/aie2_message.c
> +++ b/drivers/accel/amdxdna/aie2_message.c
[ ... ]
> @@ -798,6 +812,8 @@ aie2_cmdlist_fill_npu_elf(struct amdxdna_gem_obj *cmd_bo, void *slot, size_t *si
> u32 arg_sz;
>
> pd = amdxdna_cmd_get_payload(cmd_bo, &cmd_len);
> + if (!pd)
> + return -EINVAL;
> arg_sz = cmd_len - sizeof(*pd);
> if (cmd_len < sizeof(*pd) || arg_sz > MAX_NPU_ARGS_SIZE)
> return -EINVAL;
[Severity: Critical]
This is a pre-existing issue, but if arg_sz is 0, the bounds check incorrectly
permits a size of exactly sizeof(*npu_slot), yet args[0] is unconditionally
written:
drivers/accel/amdxdna/aie2_message.c:aie2_cmdlist_fill_npu_elf() {
...
if (*size < sizeof(*npu_slot) + arg_sz)
return -EINVAL;
memset(npu_slot, 0, sizeof(*npu_slot));
...
npu_slot->arg_cnt = 1;
npu_slot->args[0] = AIE2_EXEC_BUFFER_KERNEL_OP_TXN;
*size = struct_size(npu_slot, args, npu_slot->arg_cnt);
...
}
Does this unconditionally write args[0], causing a 4-byte out-of-bounds
write?
And if so, does it also lead to an integer underflow in
aie2_cmdlist_multi_execbuf()?
drivers/accel/amdxdna/aie2_message.c:aie2_cmdlist_multi_execbuf() {
...
size = cmdbuf_abo->mem.size - offset;
ret = aie2_cmdlist_fill_slot(cmd_buf + offset, abo, &size, &op);
amdxdna_gem_put_obj(abo);
if (ret)
return ret;
offset += size;
...
}
If the previous 4-byte overflow artificially inflates size, can offset exceed
cmdbuf_abo->mem.size, causing size to underflow on the next loop iteration
and disable bounds checks for subsequent payloads?
> diff --git a/drivers/accel/amdxdna/amdxdna_ctx.c b/drivers/accel/amdxdna/amdxdna_ctx.c
> index 31a414c3f0d96..505c249e142e6 100644
> --- a/drivers/accel/amdxdna/amdxdna_ctx.c
> +++ b/drivers/accel/amdxdna/amdxdna_ctx.c
> @@ -117,6 +117,9 @@ void *amdxdna_cmd_get_payload(struct amdxdna_gem_obj *abo, u32 *size)
> struct amdxdna_cmd *cmd = amdxdna_gem_vmap(abo);
> u32 num_masks, count;
>
> + if (size)
> + *size = 0;
> +
> if (!cmd)
> return NULL;
>
[Severity: High]
This is a pre-existing issue, but does the error path in
amdxdna_cmd_set_error() leak a GEM object reference?
drivers/accel/amdxdna/amdxdna_ctx.c:amdxdna_cmd_set_error() {
...
if (amdxdna_cmd_get_op(abo) == ERT_CMD_CHAIN) {
cc = amdxdna_cmd_get_payload(abo, NULL);
cc->error_index = (cmd_idx < cc->command_count) ? cmd_idx : 0;
abo = amdxdna_gem_get_obj(client, cc->data[0], AMDXDNA_BO_SHARE);
if (!abo)
return -EINVAL;
cmd = amdxdna_gem_vmap(abo);
if (!cmd)
return -ENOMEM;
...
}
If amdxdna_gem_vmap() fails, it returns -ENOMEM without calling
amdxdna_gem_put_obj() to release the abo obtained from amdxdna_gem_get_obj().
Does this lead to a memory leak of the GEM object under memory pressure?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260818002459.377641-1-taimuraz@kaitmazov.com?part=1
prev parent reply other threads:[~2026-08-18 0:38 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-18 0:24 [PATCH] accel/amdxdna: check the command payload before using it Taimuraz Kaitmazov
2026-08-18 0:38 ` sashiko-bot [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260818003828.0CE871F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=taimuraz@kaitmazov.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.