Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [High] drm/amdkfd: uninitialized pointer dereference in criu_restore_devices() --
commit 40984d73f07608e70e87d6e7d3692de70675fb26 Author: Wentao Liang <[email protected]> drm/amdkfd: Fix file reference leak in criu_restore_devices() This commit attempts to fix a file reference count leak in criu_restore_devices() by calling fput() when a drm_file is already set on the process device data structure. Cc: [email protected] > diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c > b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c > --- a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c > +++ b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c > @@ -2380,6 +2380,7 @@ static int criu_restore_devices(struct kfd_process *p, > } > > if (pdd->drm_file) { > + fput(drm_file); [Severity: High] Could this lead to an uninitialized pointer dereference? Looking at criu_restore_devices(), the variable drm_file is declared as an uninitialized local variable inside the loop: for (i = 0; i < args->num_devices; i++) { ... struct file *drm_file; ... if (pdd->drm_file) { fput(drm_file); ... } ... drm_file = fget(device_buckets[i].drm_fd); } At the point where fput(drm_file) is called in this new error path, drm_file has not yet been assigned a value via fget(). If this error path is taken on the first iteration, it seems like fput() would be called on uninitialized stack memory. If it happens on a subsequent iteration, could this result in a double-free of the reference from the previous iteration? > ret = -EINVAL; > goto exit; > } -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=1
