[PATCH] drm/v3d: Fix NULL pointer dereference in CPU job cleanup

[PATCH] drm/v3d: Fix NULL pointer dereference in CPU job cleanup

[Karl Mehltretter]

v3d_submit_cpu_ioctl() allocates cpu_job before initializing its embedded
drm_sched_job. If extension parsing fails, no CPU job extension is
supplied, or the BO count is invalid, it jumps to fail before
v3d_job_init().
v3d_job_cleanup() then calls drm_sched_job_cleanup() with a NULL s_fence,
causing a NULL pointer dereference.

An empty DRM_IOCTL_V3D_SUBMIT_CPU (flags == 0) is sufficient to trigger it.

Deallocate the job and clear the pointer on these paths, matching the
existing handling when v3d_job_init() fails.

v3d_job_deallocate() frees only the top-level job. If extension parsing
already allocated query or indirect-CSD state, that state still leaks on
these error paths, turning the former oops into a repeatable leak.
Fixing this safely is more involved and beyond the scope of this fix. This
patch therefore addresses only the crash.

Fixes: aafc1a2bea674 ("drm/v3d: Add a CPU job submission")
Cc: stable@vger.kernel.org
Assisted-by: Codex:gpt-5.6-sol
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
---
Tested on a Raspberry Pi 400: the unpatched kernel oopses on flags=0; with
this patch the ioctl returns -EINVAL without an oops.

 drivers/gpu/drm/v3d/v3d_submit.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/v3d/v3d_submit.c b/drivers/gpu/drm/v3d/v3d_submit.c
index 7682b24f13ec5..304950ba42a38 100644
--- a/drivers/gpu/drm/v3d/v3d_submit.c
+++ b/drivers/gpu/drm/v3d/v3d_submit.c
@@ -1313,6 +1313,7 @@ v3d_submit_cpu_ioctl(struct drm_device *dev, void *data,
 		ret = v3d_get_extensions(file_priv, args->extensions, &se, cpu_job);
 		if (ret) {
 			drm_dbg(dev, "Failed to get extensions.\n");
+			v3d_job_deallocate((void *)&cpu_job);
 			goto fail;
 		}
 	}
@@ -1321,12 +1322,14 @@ v3d_submit_cpu_ioctl(struct drm_device *dev, void *data,
 	if (!cpu_job->job_type) {
 		drm_dbg(dev, "CPU job must have a CPU job user extension.\n");
 		ret = -EINVAL;
+		v3d_job_deallocate((void *)&cpu_job);
 		goto fail;
 	}
 
 	if (args->bo_handle_count != cpu_job_bo_handle_count[cpu_job->job_type]) {
 		drm_dbg(dev, "This CPU job was not submitted with the proper number of BOs.\n");
 		ret = -EINVAL;
+		v3d_job_deallocate((void *)&cpu_job);
 		goto fail;
 	}
 
-- 
2.53.0

Re: [PATCH] drm/v3d: Fix NULL pointer dereference in CPU job cleanup

[Maíra Canal]

Hi Karl,

Thank you for your contribution! Unfortunately, this issue is already
addressed in drm-misc-next.

Best regards,
- Maíra

On 15/08/26 11:59, Karl Mehltretter wrote:
> v3d_submit_cpu_ioctl() allocates cpu_job before initializing its embedded
> drm_sched_job. If extension parsing fails, no CPU job extension is
> supplied, or the BO count is invalid, it jumps to fail before
> v3d_job_init().
> v3d_job_cleanup() then calls drm_sched_job_cleanup() with a NULL s_fence,
> causing a NULL pointer dereference.
> 
> An empty DRM_IOCTL_V3D_SUBMIT_CPU (flags == 0) is sufficient to trigger it.
> 
> Deallocate the job and clear the pointer on these paths, matching the
> existing handling when v3d_job_init() fails.
> 
> v3d_job_deallocate() frees only the top-level job. If extension parsing
> already allocated query or indirect-CSD state, that state still leaks on
> these error paths, turning the former oops into a repeatable leak.
> Fixing this safely is more involved and beyond the scope of this fix. This
> patch therefore addresses only the crash.
> 
> Fixes: aafc1a2bea674 ("drm/v3d: Add a CPU job submission")
> Cc: stable@vger.kernel.org
> Assisted-by: Codex:gpt-5.6-sol
> Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
> ---
> Tested on a Raspberry Pi 400: the unpatched kernel oopses on flags=0; with
> this patch the ioctl returns -EINVAL without an oops.
> 
>   drivers/gpu/drm/v3d/v3d_submit.c | 3 +++
>   1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/gpu/drm/v3d/v3d_submit.c b/drivers/gpu/drm/v3d/v3d_submit.c
> index 7682b24f13ec5..304950ba42a38 100644
> --- a/drivers/gpu/drm/v3d/v3d_submit.c
> +++ b/drivers/gpu/drm/v3d/v3d_submit.c
> @@ -1313,6 +1313,7 @@ v3d_submit_cpu_ioctl(struct drm_device *dev, void *data,
>   		ret = v3d_get_extensions(file_priv, args->extensions, &se, cpu_job);
>   		if (ret) {
>   			drm_dbg(dev, "Failed to get extensions.\n");
> +			v3d_job_deallocate((void *)&cpu_job);
>   			goto fail;
>   		}
>   	}
> @@ -1321,12 +1322,14 @@ v3d_submit_cpu_ioctl(struct drm_device *dev, void *data,
>   	if (!cpu_job->job_type) {
>   		drm_dbg(dev, "CPU job must have a CPU job user extension.\n");
>   		ret = -EINVAL;
> +		v3d_job_deallocate((void *)&cpu_job);
>   		goto fail;
>   	}
>   
>   	if (args->bo_handle_count != cpu_job_bo_handle_count[cpu_job->job_type]) {
>   		drm_dbg(dev, "This CPU job was not submitted with the proper number of BOs.\n");
>   		ret = -EINVAL;
> +		v3d_job_deallocate((void *)&cpu_job);
>   		goto fail;
>   	}
>   

Re: [PATCH] drm/v3d: Fix NULL pointer dereference in CPU job cleanup

[Karl Mehltretter]

On Sat, Aug 15, 2026 at 12:15:46PM +0100, Maíra Canal wrote:
> Hi Karl,
> 
> Thank you for your contribution! Unfortunately, this issue is already
> addressed in drm-misc-next.

Great to hear this is addressed in drm-misc-next. Is a
stable backport plannend for this ?

Thanks,
Karl

Re: [PATCH] drm/v3d: Fix NULL pointer dereference in CPU job cleanup

[Maíra Canal]

On 15/08/26 12:22, Karl Mehltretter wrote:
> On Sat, Aug 15, 2026 at 12:15:46PM +0100, Maíra Canal wrote:
>> Hi Karl,
>>
>> Thank you for your contribution! Unfortunately, this issue is already
>> addressed in drm-misc-next.
> 
> Great to hear this is addressed in drm-misc-next. Is a
> stable backport plannend for this ?

ATM, no, as the fix was part of a larger refactor in V3D's submission
code. Have you faced this issue in any real life scenarios? If so, I can
think of a way to backport it.

Best regards,
- Maíra

> 
> Thanks,
> Karl

Re: [PATCH] drm/v3d: Fix NULL pointer dereference in CPU job cleanup

[Karl Mehltretter]

On Sat, Aug 15, 2026 at 12:26:37PM +0100, Maíra Canal wrote:
> ATM, no, as the fix was part of a larger refactor in V3D's submission
> code. Have you faced this issue in any real life scenarios? If so, I can
> think of a way to backport it.
> 

No, I did not hit this in real use. I found it while looking at the v3d
code and then reproduced it on my Pi 400.

So there is no hurry from my side. Please decide as you like.

Thanks,
Karl