[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

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:

New issues:
- [High] Logical Use-After-Free/Double-Free introduced by attempting to manually free a job already tracked in the global submit array.
- [Low] The patch introduces calls to an undefined function `v3d_job_deallocate()`, which will cause a build failure.

Pre-existing issues:
- [Critical] Pre-existing double-free vulnerability in the extension parsing error paths for CPU jobs.
--

--- Patch [1]: [PATCH] drm/v3d: Fix NULL pointer dereference in CPU job cleanup ---
commit f37328e13f9e40584da544c634e4094ecc1b59ee
Author: Karl Mehltretter <kmehltretter@gmail.com>

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

This commit attempts to fix a NULL pointer dereference in CPU job cleanup
by manually deallocating the job and clearing the pointer when extension
parsing or BO count validation fails. It aims to match the error handling
present when v3d_job_init() fails.

> diff --git a/drivers/gpu/drm/v3d/v3d_submit.c b/drivers/gpu/drm/v3d/v3d_submit.c
> index 834d52030979d..8cabb3ba77898 100644
> --- a/drivers/gpu/drm/v3d/v3d_submit.c
> +++ b/drivers/gpu/drm/v3d/v3d_submit.c
> @@ -1573,6 +1573,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);

[Severity: Low]
Does this code break the build? It appears v3d_job_deallocate() is not
defined or declared anywhere in the kernel tree.


[Severity: High]
If v3d_job_deallocate() were defined and freed the job, would this cause a
double-free?

The cpu_job was already added to the global submit array earlier in
v3d_submit_cpu_ioctl() via:

    cpu_job = (struct v3d_cpu_job *)v3d_submit_add_job(&submit, V3D_CPU);

When this code jumps to the fail label, it executes v3d_submit_cleanup_jobs(),
which iterates over the submit.jobs array and calls v3d_job_cleanup() on
the pointer. If the job was already manually freed here, would
v3d_submit_cleanup_jobs() dereference a dangling pointer?


[Severity: Critical]
This is a pre-existing issue, but does v3d_get_extensions() leave a
dangling pointer that gets double-freed on this error path?

If a user provides an invalid sync handle, 
v3d_get_cpu_timestamp_query_params() fails and calls 
v3d_timestamp_query_info_free():

drivers/gpu/drm/v3d/v3d_sched.c:v3d_timestamp_query_info_free() {
    ...
    kvfree(query_info->queries);
    ...
}

The queries array is freed but the pointer is not set to NULL. The error
bubbles up here, and the code jumps to the fail label.

The fail path calls v3d_submit_cleanup_jobs(), which calls v3d_cpu_job_free()
on the same job, and that unconditionally calls
v3d_timestamp_query_info_free() again:

drivers/gpu/drm/v3d/v3d_submit.c:v3d_cpu_job_free() {
    ...
    v3d_timestamp_query_info_free(&job->timestamp_query,
                                  job->timestamp_query.count);
    ...
}

Will this result in a double-free of query_info->queries?

>  			goto fail;
>  		}
>  	}

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260815145914.84154-1-kmehltretter@gmail.com?part=1

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