{
  "cveId": "CVE-2023-52738",
  "url": "https://patchblox.com/security/cve/CVE-2023-52738",
  "summary": "CVE-2023-52738 is fixed in linux on 1 platform, first by DEBIAN-CVE-2023-52738, released May 21, 2024. It is not reported as exploited. Patch Radar priority: Routine.",
  "title": "linux: In the Linux kernel, the following vulnerability has been resolved:  drm/amdgpu/fence: Fix oops due to non-matching d...",
  "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\u002B0x84/0xa0 [gpu_sched] [...] Call Trace:  \u003CTASK\u003E  amdgpu_fence_driver_sw_fini\u002B0xc8/0xd0 [amdgpu]  amdgpu_device_fini_sw\u002B0x2b/0x3b0 [amdgpu]  amdgpu_driver_release_kms\u002B0x16/0x30 [amdgpu]  devm_drm_dev_init_release\u002B0x49/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\u0027d use sched.ready for that; such field is set as the latest thing on drm_sched_init(). But amdgpu seems to \u0022override\u0022 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\u0027s suggestion [0], and also removed the no_scheduler check [1].  [0] https://lore.kernel.org/amd-gfx/984ee981-2906-0eaf-ccec-9f80975cb136@amd.com/ [1] https://lore.kernel.org/amd-gfx/cd0e2994-f85f-d837-609f-7056d5fb7231@amd.com/",
  "published": "2024-05-21T16:15:13Z",
  "severity": "medium",
  "cvss": 5.3,
  "cvssVector": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
  "epss": 0.00796,
  "epssPercentile": 0.5674,
  "priority": "Routine",
  "priorityTier": 4,
  "exploited": false,
  "vendorExploited": false,
  "disclosed": false,
  "fixes": [
    {
      "platform": "linux",
      "product": "linux",
      "release": "Debian 12.15 (bookworm)",
      "fixedVersion": "6.1.12-1",
      "fix": "DEBIAN-CVE-2023-52738",
      "url": "https://patchblox.com/security/fix/linux/debian-cve-2023-52738",
      "released": "2024-05-21T16:15:13Z"
    },
    {
      "platform": "linux",
      "product": "linux",
      "release": "Debian 13.5 (trixie)",
      "fixedVersion": "6.1.12-1",
      "fix": "DEBIAN-CVE-2023-52738",
      "url": "https://patchblox.com/security/fix/linux/debian-cve-2023-52738",
      "released": "2024-05-21T16:15:13Z"
    },
    {
      "platform": "linux",
      "product": "linux",
      "release": "Debian 14",
      "fixedVersion": "6.1.12-1",
      "fix": "DEBIAN-CVE-2023-52738",
      "url": "https://patchblox.com/security/fix/linux/debian-cve-2023-52738",
      "released": "2024-05-21T16:15:13Z"
    }
  ],
  "noFixYet": [],
  "dataAsOf": "2026-11-09T19:38:12Z",
  "attribution": {
    "text": "Data: Patchblox Patch Radar",
    "url": "https://patchblox.com/security/patch-radar",
    "terms": "https://patchblox.com/security/patch-radar/use-the-data"
  }
}