Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues: - [Critical] Job scheduler tracks current->mm instead of client->mm, enabling cross-process DMA vulnerabilities when file descriptors are shared. -- --- Patch [1]: [PATCH V1] accel/amdxdna: Fix use-after-free of mm_struct in job scheduler --- commit 97cf038e79109413737ecf07de35445a6294ab64 Author: Lizhi Hou <[email protected]> accel/amdxdna: Fix use-after-free of mm_struct in job scheduler This commit fixes a use-after-free of mm_struct in the job scheduler by calling mmgrab to hold a structural reference for the lifetime of the job, paired with mmdrop in cleanup paths. > diff --git a/drivers/accel/amdxdna/amdxdna_ctx.c > b/drivers/accel/amdxdna/amdxdna_ctx.c > index 855da8c79a1cd..ea560025ae79f 100644 > --- a/drivers/accel/amdxdna/amdxdna_ctx.c > +++ b/drivers/accel/amdxdna/amdxdna_ctx.c [ ... ] > @@ -598,6 +599,7 @@ int amdxdna_cmd_submit(struct amdxdna_client *client, > > job->hwctx = hwctx; > job->mm = current->mm; > + mmgrab(job->mm); [Severity: Critical] This is a pre-existing issue and was not introduced by the patch under review, but should this use client->mm instead of current->mm? If the file descriptor is shared across processes (for example, via fork), using current->mm binds the hardware job liveness check to the ioctl caller rather than the PASID owner. Could this lead to cross-process DMA if Process A opens the device, binds IOMMU SVA to its mm (allocating PASID X), forks Process B, and then exits? The IOMMU would free PASID X, which could be reallocated to a new Process C. If Process B then calls the submit ioctl, amdxdna_cmd_submit() assigns Process B's mm to job->mm. Since Process B is still alive, the liveness check in aie2_sched_job_run() would pass, and the hardware might access Process C's memory under Process B's control using the recycled PASID. > > job->fence = amdxdna_fence_create(hwctx); -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=1
