cve-2024-56552
Vulnerability from cvelistv5
Published
2024-12-27 14:22
Modified
2025-01-20 06:22
Severity ?
Summary
In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc_submit: fix race around suspend_pending Currently in some testcases we can trigger: xe 0000:03:00.0: [drm] Assertion `exec_queue_destroyed(q)` failed! .... WARNING: CPU: 18 PID: 2640 at drivers/gpu/drm/xe/xe_guc_submit.c:1826 xe_guc_sched_done_handler+0xa54/0xef0 [xe] xe 0000:03:00.0: [drm] *ERROR* GT1: DEREGISTER_DONE: Unexpected engine state 0x00a1, guc_id=57 Looking at a snippet of corresponding ftrace for this GuC id we can see: 162.673311: xe_sched_msg_add: dev=0000:03:00.0, gt=1 guc_id=57, opcode=3 162.673317: xe_sched_msg_recv: dev=0000:03:00.0, gt=1 guc_id=57, opcode=3 162.673319: xe_exec_queue_scheduling_disable: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0x29, flags=0x0 162.674089: xe_exec_queue_kill: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0x29, flags=0x0 162.674108: xe_exec_queue_close: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0xa9, flags=0x0 162.674488: xe_exec_queue_scheduling_done: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0xa9, flags=0x0 162.678452: xe_exec_queue_deregister: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0xa1, flags=0x0 It looks like we try to suspend the queue (opcode=3), setting suspend_pending and triggering a disable_scheduling. The user then closes the queue. However the close will also forcefully signal the suspend fence after killing the queue, later when the G2H response for disable_scheduling comes back we have now cleared suspend_pending when signalling the suspend fence, so the disable_scheduling now incorrectly tries to also deregister the queue. This leads to warnings since the queue has yet to even be marked for destruction. We also seem to trigger errors later with trying to double unregister the same queue. To fix this tweak the ordering when handling the response to ensure we don't race with a disable_scheduling that didn't actually intend to perform an unregister. The destruction path should now also correctly wait for any pending_disable before marking as destroyed. (cherry picked from commit f161809b362f027b6d72bd998e47f8f0bad60a2e)
References
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/5ddcb50b700221fa7d7be2adcb3d7d7afe8633dd
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/87651f31ae4e6e6e7e6c7270b9b469405e747407
Impacted products
Vendor Product Version
Linux Linux Version: dd08ebf6c3525a7ea2186e636df064ea47281987
Version: dd08ebf6c3525a7ea2186e636df064ea47281987
 Create a notification for this product.
   Linux Linux Version: 6.8
 Create a notification for this product.
Show details on NVD website

To clipboard 

{
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "drivers/gpu/drm/xe/xe_guc_submit.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "5ddcb50b700221fa7d7be2adcb3d7d7afe8633dd",
              "status": "affected",
              "version": "dd08ebf6c3525a7ea2186e636df064ea47281987",
              "versionType": "git"
            },
            {
              "lessThan": "87651f31ae4e6e6e7e6c7270b9b469405e747407",
              "status": "affected",
              "version": "dd08ebf6c3525a7ea2186e636df064ea47281987",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "drivers/gpu/drm/xe/xe_guc_submit.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "6.8"
            },
            {
              "lessThan": "6.8",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.12.*",
              "status": "unaffected",
              "version": "6.12.4",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "6.13",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/xe/guc_submit: fix race around suspend_pending\n\nCurrently in some testcases we can trigger:\n\nxe 0000:03:00.0: [drm] Assertion `exec_queue_destroyed(q)` failed!\n....\nWARNING: CPU: 18 PID: 2640 at drivers/gpu/drm/xe/xe_guc_submit.c:1826 xe_guc_sched_done_handler+0xa54/0xef0 [xe]\nxe 0000:03:00.0: [drm] *ERROR* GT1: DEREGISTER_DONE: Unexpected engine state 0x00a1, guc_id=57\n\nLooking at a snippet of corresponding ftrace for this GuC id we can see:\n\n162.673311: xe_sched_msg_add:     dev=0000:03:00.0, gt=1 guc_id=57, opcode=3\n162.673317: xe_sched_msg_recv:    dev=0000:03:00.0, gt=1 guc_id=57, opcode=3\n162.673319: xe_exec_queue_scheduling_disable: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0x29, flags=0x0\n162.674089: xe_exec_queue_kill:   dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0x29, flags=0x0\n162.674108: xe_exec_queue_close:  dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0xa9, flags=0x0\n162.674488: xe_exec_queue_scheduling_done: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0xa9, flags=0x0\n162.678452: xe_exec_queue_deregister: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0xa1, flags=0x0\n\nIt looks like we try to suspend the queue (opcode=3), setting\nsuspend_pending and triggering a disable_scheduling. The user then\ncloses the queue. However the close will also forcefully signal the\nsuspend fence after killing the queue, later when the G2H response for\ndisable_scheduling comes back we have now cleared suspend_pending when\nsignalling the suspend fence, so the disable_scheduling now incorrectly\ntries to also deregister the queue. This leads to warnings since the queue\nhas yet to even be marked for destruction. We also seem to trigger\nerrors later with trying to double unregister the same queue.\n\nTo fix this tweak the ordering when handling the response to ensure we\ndon\u0027t race with a disable_scheduling that didn\u0027t actually intend to\nperform an unregister.  The destruction path should now also correctly\nwait for any pending_disable before marking as destroyed.\n\n(cherry picked from commit f161809b362f027b6d72bd998e47f8f0bad60a2e)"
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2025-01-20T06:22:45.889Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/5ddcb50b700221fa7d7be2adcb3d7d7afe8633dd"
        },
        {
          "url": "https://git.kernel.org/stable/c/87651f31ae4e6e6e7e6c7270b9b469405e747407"
        }
      ],
      "title": "drm/xe/guc_submit: fix race around suspend_pending",
      "x_generator": {
        "engine": "bippy-5f407fcff5a0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2024-56552",
    "datePublished": "2024-12-27T14:22:54.140Z",
    "dateReserved": "2024-12-27T14:03:05.990Z",
    "dateUpdated": "2025-01-20T06:22:45.889Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.1",
  "vulnerability-lookup:meta": {
    "nvd": "{\"cve\":{\"id\":\"CVE-2024-56552\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2024-12-27T15:15:13.970\",\"lastModified\":\"2024-12-27T15:15:13.970\",\"vulnStatus\":\"Received\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"In the Linux kernel, the following vulnerability has been resolved:\\n\\ndrm/xe/guc_submit: fix race around suspend_pending\\n\\nCurrently in some testcases we can trigger:\\n\\nxe 0000:03:00.0: [drm] Assertion `exec_queue_destroyed(q)` failed!\\n....\\nWARNING: CPU: 18 PID: 2640 at drivers/gpu/drm/xe/xe_guc_submit.c:1826 xe_guc_sched_done_handler+0xa54/0xef0 [xe]\\nxe 0000:03:00.0: [drm] *ERROR* GT1: DEREGISTER_DONE: Unexpected engine state 0x00a1, guc_id=57\\n\\nLooking at a snippet of corresponding ftrace for this GuC id we can see:\\n\\n162.673311: xe_sched_msg_add:     dev=0000:03:00.0, gt=1 guc_id=57, opcode=3\\n162.673317: xe_sched_msg_recv:    dev=0000:03:00.0, gt=1 guc_id=57, opcode=3\\n162.673319: xe_exec_queue_scheduling_disable: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0x29, flags=0x0\\n162.674089: xe_exec_queue_kill:   dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0x29, flags=0x0\\n162.674108: xe_exec_queue_close:  dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0xa9, flags=0x0\\n162.674488: xe_exec_queue_scheduling_done: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0xa9, flags=0x0\\n162.678452: xe_exec_queue_deregister: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0xa1, flags=0x0\\n\\nIt looks like we try to suspend the queue (opcode=3), setting\\nsuspend_pending and triggering a disable_scheduling. The user then\\ncloses the queue. However the close will also forcefully signal the\\nsuspend fence after killing the queue, later when the G2H response for\\ndisable_scheduling comes back we have now cleared suspend_pending when\\nsignalling the suspend fence, so the disable_scheduling now incorrectly\\ntries to also deregister the queue. This leads to warnings since the queue\\nhas yet to even be marked for destruction. We also seem to trigger\\nerrors later with trying to double unregister the same queue.\\n\\nTo fix this tweak the ordering when handling the response to ensure we\\ndon\u0027t race with a disable_scheduling that didn\u0027t actually intend to\\nperform an unregister.  The destruction path should now also correctly\\nwait for any pending_disable before marking as destroyed.\\n\\n(cherry picked from commit f161809b362f027b6d72bd998e47f8f0bad60a2e)\"}],\"metrics\":{},\"references\":[{\"url\":\"https://git.kernel.org/stable/c/5ddcb50b700221fa7d7be2adcb3d7d7afe8633dd\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/87651f31ae4e6e6e7e6c7270b9b469405e747407\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"}]}}"
  }
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
  • Confirmed: The vulnerability is confirmed from an analyst perspective.
  • Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
  • Patched: This vulnerability was successfully patched by the user reporting the sighting.
  • Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
  • Not confirmed: The user expresses doubt about the veracity of the vulnerability.
  • Not patched: This vulnerability was not successfully patched by the user reporting the sighting.