CVE-2023-52738
AMDGPU Null Pointer Dereference in drm_sched_fini
Description
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/fence: Fix oops due to non-matching drm_sched init/fini Currently amdgpu calls drm_sched_fini() from the fence driver sw fini routine - such function is expected to be called only after the respective init function - drm_sched_init() - was executed successfully. Happens that we faced a driver probe failure in the Steam Deck recently, and the function drm_sched_fini() was called even without its counter-part had been previously called, causing the following oops: amdgpu: probe of 0000:04:00.0 failed with error -110 BUG: kernel NULL pointer dereference, address: 0000000000000090 PGD 0 P4D 0 Oops: 0002 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 609 Comm: systemd-udevd Not tainted 6.2.0-rc3-gpiccoli #338 Hardware name: Valve Jupiter/Jupiter, BIOS F7A0113 11/04/2022 RIP: 0010:drm_sched_fini+0x84/0xa0 [gpu_sched] [...] Call Trace: <TASK> amdgpu_fence_driver_sw_fini+0xc8/0xd0 [amdgpu] amdgpu_device_fini_sw+0x2b/0x3b0 [amdgpu] amdgpu_driver_release_kms+0x16/0x30 [amdgpu] devm_drm_dev_init_release+0x49/0x70 [...] To prevent that, check if the drm_sched was properly initialized for a given ring before calling its fini counter-part. Notice ideally we'd use sched.ready for that; such field is set as the latest thing on drm_sched_init(). But amdgpu seems to "override" the meaning of such field - in the above oops for example, it was a GFX ring causing the crash, and the sched.ready field was set to true in the ring init routine, regardless of the state of the DRM scheduler. Hence, we ended-up using sched.ops as per Christian's suggestion [0], and also removed the no_scheduler check [1]. [0] https://lore.kernel.org/amd-gfx/[email protected]/ [1] https://lore.kernel.org/amd-gfx/[email protected]/
INFO
Published Date :
May 21, 2024, 4:15 p.m.
Last Modified :
April 2, 2025, 2:51 p.m.
Source :
416baaa9-dc9f-4396-8d5f-8c081fb06d67
Remotely Exploitable :
Yes !
Impact Score :
1.4
Exploitability Score :
3.9
References to Advisories, Solutions, and Tools
Here, you will find a curated list of external links that provide in-depth
information, practical solutions, and valuable tools related to
CVE-2023-52738.
We scan GitHub repositories to detect new proof-of-concept exploits. Following list is a collection of public exploits and proof-of-concepts, which have been published on GitHub (sorted by the most recently updated).
Results are limited to the first 15 repositories due to potential performance issues.
The following list is the news that have been mention
CVE-2023-52738 vulnerability anywhere in the article.
The following table lists the changes that have been made to the
CVE-2023-52738 vulnerability over time.
Vulnerability history details can be useful for understanding the evolution of a vulnerability, and for identifying the most recent changes that may impact the vulnerability's severity, exploitability, or other characteristics.
-
Initial Analysis by [email protected]
Apr. 02, 2025
Action Type Old Value New Value Added CWE CWE-476 Added CPE Configuration OR *cpe:2.3:o:linux:linux_kernel:6.2:rc1:*:*:*:*:*:* *cpe:2.3:o:linux:linux_kernel:6.2:rc2:*:*:*:*:*:* *cpe:2.3:o:linux:linux_kernel:6.2:rc3:*:*:*:*:*:* *cpe:2.3:o:linux:linux_kernel:6.2:rc4:*:*:*:*:*:* *cpe:2.3:o:linux:linux_kernel:6.2:rc5:*:*:*:*:*:* *cpe:2.3:o:linux:linux_kernel:6.2:rc6:*:*:*:*:*:* *cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* versions from (including) 5.14.10 up to (excluding) 5.15.94 *cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* versions from (including) 5.16 up to (including) 6.1.12 *cpe:2.3:o:linux:linux_kernel:6.2:rc7:*:*:*:*:*:* Added Reference Type CVE: https://git.kernel.org/stable/c/2bcbbef9cace772f5b7128b11401c515982de34b Types: Patch Added Reference Type kernel.org: https://git.kernel.org/stable/c/2bcbbef9cace772f5b7128b11401c515982de34b Types: Patch Added Reference Type CVE: https://git.kernel.org/stable/c/2e557c8ca2c585bdef591b8503ba83b85f5d0afd Types: Patch Added Reference Type kernel.org: https://git.kernel.org/stable/c/2e557c8ca2c585bdef591b8503ba83b85f5d0afd Types: Patch Added Reference Type CVE: https://git.kernel.org/stable/c/5ad7bbf3dba5c4a684338df1f285080f2588b535 Types: Patch Added Reference Type kernel.org: https://git.kernel.org/stable/c/5ad7bbf3dba5c4a684338df1f285080f2588b535 Types: Patch -
CVE Modified by af854a3a-2127-422b-91ae-364da2661108
Nov. 21, 2024
Action Type Old Value New Value Added Reference https://git.kernel.org/stable/c/2bcbbef9cace772f5b7128b11401c515982de34b Added Reference https://git.kernel.org/stable/c/2e557c8ca2c585bdef591b8503ba83b85f5d0afd Added Reference https://git.kernel.org/stable/c/5ad7bbf3dba5c4a684338df1f285080f2588b535 -
CVE Modified by 134c704f-9b21-4f2e-91b3-4a467353bcc0
Nov. 06, 2024
Action Type Old Value New Value Added CVSS V3.1 CISA-ADP AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L -
CVE Modified by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
May. 29, 2024
Action Type Old Value New Value -
CVE Received by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
May. 21, 2024
Action Type Old Value New Value Added Description In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/fence: Fix oops due to non-matching drm_sched init/fini Currently amdgpu calls drm_sched_fini() from the fence driver sw fini routine - such function is expected to be called only after the respective init function - drm_sched_init() - was executed successfully. Happens that we faced a driver probe failure in the Steam Deck recently, and the function drm_sched_fini() was called even without its counter-part had been previously called, causing the following oops: amdgpu: probe of 0000:04:00.0 failed with error -110 BUG: kernel NULL pointer dereference, address: 0000000000000090 PGD 0 P4D 0 Oops: 0002 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 609 Comm: systemd-udevd Not tainted 6.2.0-rc3-gpiccoli #338 Hardware name: Valve Jupiter/Jupiter, BIOS F7A0113 11/04/2022 RIP: 0010:drm_sched_fini+0x84/0xa0 [gpu_sched] [...] Call Trace: <TASK> amdgpu_fence_driver_sw_fini+0xc8/0xd0 [amdgpu] amdgpu_device_fini_sw+0x2b/0x3b0 [amdgpu] amdgpu_driver_release_kms+0x16/0x30 [amdgpu] devm_drm_dev_init_release+0x49/0x70 [...] To prevent that, check if the drm_sched was properly initialized for a given ring before calling its fini counter-part. Notice ideally we'd use sched.ready for that; such field is set as the latest thing on drm_sched_init(). But amdgpu seems to "override" the meaning of such field - in the above oops for example, it was a GFX ring causing the crash, and the sched.ready field was set to true in the ring init routine, regardless of the state of the DRM scheduler. Hence, we ended-up using sched.ops as per Christian's suggestion [0], and also removed the no_scheduler check [1]. [0] https://lore.kernel.org/amd-gfx/[email protected]/ [1] https://lore.kernel.org/amd-gfx/[email protected]/ Added Reference kernel.org https://git.kernel.org/stable/c/2e557c8ca2c585bdef591b8503ba83b85f5d0afd [No types assigned] Added Reference kernel.org https://git.kernel.org/stable/c/2bcbbef9cace772f5b7128b11401c515982de34b [No types assigned] Added Reference kernel.org https://git.kernel.org/stable/c/5ad7bbf3dba5c4a684338df1f285080f2588b535 [No types assigned]
CWE - Common Weakness Enumeration
While CVE identifies
specific instances of vulnerabilities, CWE categorizes the common flaws or
weaknesses that can lead to vulnerabilities. CVE-2023-52738 is
associated with the following CWEs:
Common Attack Pattern Enumeration and Classification (CAPEC)
Common Attack Pattern Enumeration and Classification
(CAPEC)
stores attack patterns, which are descriptions of the common attributes and
approaches employed by adversaries to exploit the CVE-2023-52738
weaknesses.