linux-stable.git/drivers/accel, branch v7.1.6

accel: ethosu: Handle U85 internal chaining buffer

2026-08-03T09:25:33+00:00

[ Upstream commit 6b7e0066294d23ad1fd37f4326c32e8090fb8b65 ]

The Ethos-U85 supports an internal chaining buffer as temporary storage
between some operations. When chaining is activated, the IFM/OFM region
setting selects a chaining buffer rather than a region, and the IFM/OFM
base addresses don't matter. In this case, the feature matrix size
calculations should be skipped. Otherwise, the command stream will be
intermittently rejected depending on prior feature matrix base
addresses.

Fixes: 5a5e9c0228e6 ("accel: Add Arm Ethos-U NPU driver")
Acked-by: Tomeu Vizoso 
Link: https://patch.msgid.link/20260720231450.485221-2-robh@kernel.org
Signed-off-by: Rob Herring (Arm) 
Signed-off-by: Sasha Levin

accel: ethosu: Fix element size accounting for cmd stream validation

2026-08-03T09:25:33+00:00

[ Upstream commit 18a551482a4a326790698b273e76d7575a51a57d ]

There are 2 issues with the element size handling in the command stream
validation which result in too small of a size calculated when the
element size is 16/32/64 bits.

For NHWC format, the element size is simply missing from the
calculation.

The bitfield for the element size is different between IFM/IFM2 and
OFM. IFM and IFM2 encode the precision in parameter bits 2:3, while OFM
uses bits 1:2.

Fixes: 5a5e9c0228e6 ("accel: Add Arm Ethos-U NPU driver")
Acked-by: Tomeu Vizoso 
Link: https://patch.msgid.link/20260720231450.485221-1-robh@kernel.org
Signed-off-by: Rob Herring (Arm) 
Signed-off-by: Sasha Levin

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

2026-08-03T09:25:23+00:00

[ Upstream commit faebb7ba1ac65fa5810b640df02ce04e509fdc11 ]

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
Signed-off-by: Sasha Levin

accel/ivpu: Fix wrong register read in LNL failure diagnostics

2026-08-03T09:25:21+00:00

[ Upstream commit e4159045c2704dfe146f0ccb0445d9d074cd6882 ]

diagnose_failure_lnl() read VPU_HW_BTRS_MTL_INTERRUPT_STAT instead of
VPU_HW_BTRS_LNL_INTERRUPT_STAT, which on LNL and newer parts is a
different register with a different bit layout, so failure diagnostics
decoded the wrong register and reported a bogus error cause.
Read the LNL interrupt status register instead.

Fixes: 8a27ad81f7d3 ("accel/ivpu: Split IP and buttress code")
Reviewed-by: Andrzej Kacprowski 
Signed-off-by: Karol Wachowski 
Link: https://patch.msgid.link/20260710101331.1899505-1-karol.wachowski@linux.intel.com
Signed-off-by: Sasha Levin

accel/ivpu: Reject firmware log with size smaller than header

2026-07-24T14:21:12+00:00

commit ddb44baed257560f192b145ed36cf8c0a412de47 upstream.

fw_log_from_bo() validates the tracing buffer header_size and that the
log fits within the BO, but never checks that log->size is at least
log->header_size. fw_log_print_buffer() then computes:

  u32 data_size = log->size - log->header_size;

which underflows to a near-U32_MAX value when firmware reports a log whose
size is smaller than its header. That huge data_size defeats the
log_start/log_end bounds clamps added by commit dd1311bcf0e6 ("accel/ivpu:
Add bounds checks for firmware log indices"), so fw_log_print_lines() reads
far past the small real data region of the BO. A size of 0 also makes
fw_log_from_bo() advance the offset by 0, causing the callers to loop
forever on the same header.

Reject logs whose size is smaller than the header (which also rejects
size == 0).

Fixes: d4e4257afa6e ("accel/ivpu: Add firmware tracing support")
Cc: stable@vger.kernel.org
Signed-off-by: Jhonraushan 
Reviewed-by: Karol Wachowski 
Signed-off-by: Karol Wachowski 
Link: https://patch.msgid.link/20260715074206.867712-1-raushan.jhon@gmail.com
Signed-off-by: Greg Kroah-Hartman

accel/amdxdna: Use caller client for debug BO sync

2026-07-24T14:21:11+00:00

commit 7caf2a2351d4053075670ff3e26a6815da0a9e1e upstream.

amdxdna_drm_sync_bo_ioctl() looks up args->handle in the ioctl caller's
drm_file. For SYNC_DIRECT_FROM_DEVICE, it then calls
amdxdna_hwctx_sync_debug_bo(), but passes abo->client.

amdxdna_hwctx_sync_debug_bo() uses the passed client both as the handle
namespace for debug_bo_hdl and as the owner of the hardware context xarray.
Those must match the file that supplied args->handle. The BO's stored
client pointer is object state, not the ioctl context.

Pass filp->driver_priv instead, matching the original handle lookup.

Fixes: 7ea046838021 ("accel/amdxdna: Support firmware debug buffer")
Cc: stable@vger.kernel.org # v6.19+
Signed-off-by: Shuvam Pandey 
Reviewed-by: Lizhi Hou 
Signed-off-by: Lizhi Hou 
Link: https://patch.msgid.link/178155468039.81818.12173237984867749651@gmail.com
Signed-off-by: Greg Kroah-Hartman

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

2026-07-24T14:21:11+00:00

commit 261c1fe3327ad24508f54552c6366e3e4db82c15 upstream.

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
Signed-off-by: Greg Kroah-Hartman

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

2026-07-24T14:21:11+00:00

commit 38953513d7313992676d4136cd425cdb70c6278e upstream.

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
Signed-off-by: Greg Kroah-Hartman

accel/amdxdna: Fix use-after-free in amdxdna_gem_dmabuf_mmap()

2026-07-24T14:21:11+00:00

commit 63bbf9ac5dde2ba85e7b39d0a0b7d540e6252ba4 upstream.

When vm_insert_pages() fails, the error path calls vma->vm_ops->close(vma)
which internally calls drm_gem_vm_close() → drm_gem_object_put(),
releasing the GEM object reference acquired at the start of the function.
However, the close_vma label then falls through to put_obj, which calls
drm_gem_object_put() a second time on the same object.

If the first put releases the last reference, the object is freed and the
second put accesses freed memory, causing a use-after-free.

Fix by returning directly from close_vma instead of falling through to
put_obj, since the close handler already performs all necessary cleanup
including the object put.

Cc: stable@vger.kernel.org
Fixes: e486147c912f ("accel/amdxdna: Add BO import and export")
Signed-off-by: Wentao Liang 
Reviewed-by: Lizhi Hou 
Signed-off-by: Lizhi Hou 
Link: https://patch.msgid.link/20260625113239.49764-1-vulab@iscas.ac.cn
Signed-off-by: Greg Kroah-Hartman

accel/amdxdna: Fix potential amdxdna_umap lifetime race

2026-07-24T14:20:44+00:00

[ Upstream commit 14f172eff9c19f8043a9858845f33cd034f3a41e ]

amdxdna_umap_release() calls the blocking mmu_interval_notifier_remove()
before removing the object from abo->mem.umap_list. If
aie2_populate_range() runs concurrently, it may obtain a reference to an
amdxdna_umap that is being released, leading to a potential use-after-free.

Use kref_get_unless_zero() in aie2_populate_range() when acquiring a
reference. If the reference count has already dropped to zero, release
is in progress and the entry is skipped.

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