CVE-2023-53351
published 2025-09-17CVE-2023-53351: In the Linux kernel, the following vulnerability has been resolved: drm/sched: Check scheduler work queue before calling timeout handling During an IGT GPU…
PriorityP420medium5.5CVSS 3.1
AVLACLPRLUINSUCNINAH
EPSS
0.16%
5.9th percentile
In the Linux kernel, the following vulnerability has been resolved:
drm/sched: Check scheduler work queue before calling timeout handling
During an IGT GPU reset test we see again oops despite of
commit 0c8c901aaaebc9 (drm/sched: Check scheduler ready before calling
timeout handling).
It uses ready condition whether to call drm_sched_fault which unwind
the TDR leads to GPU reset.
However it looks the ready condition is overloaded with other meanings,
for example, for the following stack is related GPU reset :
0 gfx_v9_0_cp_gfx_start
1 gfx_v9_0_cp_gfx_resume
2 gfx_v9_0_cp_resume
3 gfx_v9_0_hw_init
4 gfx_v9_0_resume
5 amdgpu_device_ip_resume_phase2
does the following:
/* start the ring */
gfx_v9_0_cp_gfx_start(adev);
ring->sched.ready = true;
The same approach is for other ASICs as well :
gfx_v8_0_cp_gfx_resume
gfx_v10_0_kiq_resume, etc...
As a result, our GPU reset test causes GPU fault which calls unconditionally gfx_v9_0_fault
and then drm_sched_fault. However now it depends on whether the interrupt service routine
drm_sched_fault is executed after gfx_v9_0_cp_gfx_start is completed which sets the ready
field of the scheduler to true even for uninitialized schedulers and causes oops vs
no fault or when ISR drm_sched_fault is completed prior gfx_v9_0_cp_gfx_start and
NULL pointer dereference does not occur.
Use the field timeout_wq to prevent oops for uninitialized schedulers.
The field could be initialized by the work queue of resetting the domain.
v1: Corrections to commit message (Luben)
Affected
9 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| debian | linux | < linux 6.3.7-1 (forky) | linux 6.3.7-1 (forky) |
| linux | linux | — | — |
| linux | linux | >= 11b3b9f461c5c4f700f6c8da202fcc2fd6418e1f < c43a96fc00b662cef1ef0eb22d40441ce2abae8f | c43a96fc00b662cef1ef0eb22d40441ce2abae8f |
| linux | linux | >= 11b3b9f461c5c4f700f6c8da202fcc2fd6418e1f < 2da5bffe9eaa5819a868e8eaaa11b3fd0f16a691 | 2da5bffe9eaa5819a868e8eaaa11b3fd0f16a691 |
| linux | linux_kernel | — | — |
| linux | linux_kernel | — | — |
| linux | linux_kernel | >= 0 < 6.3.7-1 | 6.3.7-1 |
| linux | linux_kernel | >= 0 < 6.3.7-1 | 6.3.7-1 |
| linux | linux_kernel | >= 6.3.1 < 6.3.4 | 6.3.4 |
CVSS provenance
nvdv3.15.5MEDIUMCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
osv5.5MEDIUM
vendor_debian5.5LOW
vendor_redhat5.5MEDIUM
Stop checking back — get the weekly exploitation signal.
Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.
Red Hat
kernel: Linux kernel: Denial of Service in DRM scheduler due to improper work queue handling
vendor_redhat·2025-09-17·CVSS 5.5
CVE-2023-53351 [MEDIUM] CWE-909 kernel: Linux kernel: Denial of Service in DRM scheduler due to improper work queue handling
kernel: Linux kernel: Denial of Service in DRM scheduler due to improper work queue handling
In the Linux kernel, the following vulnerability has been resolved:
drm/sched: Check scheduler work queue before calling timeout handling
During an IGT GPU reset test we see again oops despite of
commit 0c8c901aaaebc9 (drm/sched: Check scheduler ready before calling
timeout handling).
It uses ready condition whether to call drm_sched_fault which unwind
the TDR leads to GPU reset.
However it looks the ready condition is overloaded with other meanings,
for example, for the following stack is related GPU reset :
0 gfx_v9_0_cp_gfx_start
1 gfx_v9_0_cp_gfx_resume
2 gfx_v9_0_cp_resume
3 gfx_v9_0_hw_init
4 gfx_v9_0_resume
5 amdgpu_device_ip_resume_phase2
does the following:
/* start the ring */
gfx_v9_0_c
Debian
CVE-2023-53351: linux - In the Linux kernel, the following vulnerability has been resolved: drm/sched: ...
vendor_debian·2023·CVSS 5.5
CVE-2023-53351 [MEDIUM] CVE-2023-53351: linux - In the Linux kernel, the following vulnerability has been resolved: drm/sched: ...
In the Linux kernel, the following vulnerability has been resolved: drm/sched: Check scheduler work queue before calling timeout handling During an IGT GPU reset test we see again oops despite of commit 0c8c901aaaebc9 (drm/sched: Check scheduler ready before calling timeout handling). It uses ready condition whether to call drm_sched_fault which unwind the TDR leads to GPU reset. However it looks the ready condition is overloaded with other meanings, for example, for the following stack is related GPU reset : 0 gfx_v9_0_cp_gfx_start 1 gfx_v9_0_cp_gfx_resume 2 gfx_v9_0_cp_resume 3 gfx_v9_0_hw_init 4 gfx_v9_0_resume 5 amdgpu_device_ip_resume_phase2 does the following: /* start the ring */ gfx_v9_0_cp_gfx_start(adev); ring->sched.ready = true; The same approach is for other ASICs as well : gf
GHSA
GHSA-3jgj-55q7-3rwv: In the Linux kernel, the following vulnerability has been resolved:
drm/sched: Check scheduler work queue before calling timeout handling
During an
ghsa_unreviewed·2025-09-17
CVE-2023-53351 [MEDIUM] CWE-908 GHSA-3jgj-55q7-3rwv: In the Linux kernel, the following vulnerability has been resolved:
drm/sched: Check scheduler work queue before calling timeout handling
During an
In the Linux kernel, the following vulnerability has been resolved:
drm/sched: Check scheduler work queue before calling timeout handling
During an IGT GPU reset test we see again oops despite of
commit 0c8c901aaaebc9 (drm/sched: Check scheduler ready before calling
timeout handling).
It uses ready condition whether to call drm_sched_fault which unwind
the TDR leads to GPU reset.
However it looks the ready condition is overloaded with other meanings,
for example, for the following stack is related GPU reset :
0 gfx_v9_0_cp_gfx_start
1 gfx_v9_0_cp_gfx_resume
2 gfx_v9_0_cp_resume
3 gfx_v9_0_hw_init
4 gfx_v9_0_resume
5 amdgpu_device_ip_resume_phase2
does the following:
/* start the ring */
gfx_v9_0_cp_gfx_start(adev);
ring->sched.ready = true;
The same approach is for other ASICs as wel
OSV
CVE-2023-53351: In the Linux kernel, the following vulnerability has been resolved: drm/sched: Check scheduler work queue before calling timeout handling During an IG
osv·2025-09-17·CVSS 5.5
CVE-2023-53351 [MEDIUM] CVE-2023-53351: In the Linux kernel, the following vulnerability has been resolved: drm/sched: Check scheduler work queue before calling timeout handling During an IG
In the Linux kernel, the following vulnerability has been resolved: drm/sched: Check scheduler work queue before calling timeout handling During an IGT GPU reset test we see again oops despite of commit 0c8c901aaaebc9 (drm/sched: Check scheduler ready before calling timeout handling). It uses ready condition whether to call drm_sched_fault which unwind the TDR leads to GPU reset. However it looks the ready condition is overloaded with other meanings, for example, for the following stack is related GPU reset : 0 gfx_v9_0_cp_gfx_start 1 gfx_v9_0_cp_gfx_resume 2 gfx_v9_0_cp_resume 3 gfx_v9_0_hw_init 4 gfx_v9_0_resume 5 amdgpu_device_ip_resume_phase2 does the following: /* start the ring */ gfx_v9_0_cp_gfx_start(adev); ring->sched.ready = true; The same approach is for other ASICs as well : gf
No detection rules found.
No public exploits indexed.
2025-09-17
Published