drm/scheduler: set entity to NULL in drm_sched_entity_pop_job()
It already happend a few times that patches slipped through which implemented access to an entity through a job that was already removed from the entities queue. Since jobs and entities might have different lifecycles, this can potentially cause UAF bugs. In order to make it obvious that a jobs entity pointer shouldn't be accessed after drm_sched_entity_pop_job() was called successfully, set the jobs entity pointer to NULL once the job is removed from the entity queue. Moreover, debugging a potential NULL pointer dereference is way easier than potentially corrupted memory through a UAF. Signed-off-by: Danilo Krummrich <dakr@redhat.com> Link: https://lore.kernel.org/r/20230418100453.4433-1-dakr@redhat.com Reviewed-by: Luben Tuikov <luben.tuikov@amd.com> Signed-off-by: Luben Tuikov <luben.tuikov@amd.com>
This commit is contained in:
parent
4aa35a0130
commit
96c7c2f4d5
|
@ -448,6 +448,12 @@ struct drm_sched_job *drm_sched_entity_pop_job(struct drm_sched_entity *entity)
|
|||
drm_sched_rq_update_fifo(entity, next->submit_ts);
|
||||
}
|
||||
|
||||
/* Jobs and entities might have different lifecycles. Since we're
|
||||
* removing the job from the entities queue, set the jobs entity pointer
|
||||
* to NULL to prevent any future access of the entity through this job.
|
||||
*/
|
||||
sched_job->entity = NULL;
|
||||
|
||||
return sched_job;
|
||||
}
|
||||
|
||||
|
|
|
@ -42,6 +42,10 @@
|
|||
* the hardware.
|
||||
*
|
||||
* The jobs in a entity are always scheduled in the order that they were pushed.
|
||||
*
|
||||
* Note that once a job was taken from the entities queue and pushed to the
|
||||
* hardware, i.e. the pending queue, the entity must not be referenced anymore
|
||||
* through the jobs entity pointer.
|
||||
*/
|
||||
|
||||
#include <linux/kthread.h>
|
||||
|
|
Loading…
Reference in New Issue