GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration

GHSA-78R6-645F-335Q

Vulnerability from github – Published: 2024-03-26 18:32 – Updated: 2025-03-17 15:31
VLAI
Details

In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Refactor DMCUB enter/exit idle interface

[Why] We can hang in place trying to send commands when the DMCUB isn't powered on.

[How] We need to exit out of the idle state prior to sending a command, but the process that performs the exit also invokes a command itself.

Fixing this issue involves the following:

  1. Using a software state to track whether or not we need to start the process to exit idle or notify idle.

It's possible for the hardware to have exited an idle state without driver knowledge, but entering one is always restricted to a driver allow - which makes the SW state vs HW state mismatch issue purely one of optimization, which should seldomly be hit, if at all.

  1. Refactor any instances of exit/notify idle to use a single wrapper that maintains this SW state.

This works simialr to dc_allow_idle_optimizations, but works at the DMCUB level and makes sure the state is marked prior to any notify/exit idle so we don't enter an infinite loop.

  1. Make sure we exit out of idle prior to sending any commands or waiting for DMCUB idle.

This patch takes care of 1/2. A future patch will take care of wrapping DMCUB command submission with calls to this new interface.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-52625"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-03-26T18:15:09Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: Refactor DMCUB enter/exit idle interface\n\n[Why]\nWe can hang in place trying to send commands when the DMCUB isn\u0027t\npowered on.\n\n[How]\nWe need to exit out of the idle state prior to sending a command,\nbut the process that performs the exit also invokes a command itself.\n\nFixing this issue involves the following:\n\n1. Using a software state to track whether or not we need to start\n   the process to exit idle or notify idle.\n\nIt\u0027s possible for the hardware to have exited an idle state without\ndriver knowledge, but entering one is always restricted to a driver\nallow - which makes the SW state vs HW state mismatch issue purely one\nof optimization, which should seldomly be hit, if at all.\n\n2. Refactor any instances of exit/notify idle to use a single wrapper\n   that maintains this SW state.\n\nThis works simialr to dc_allow_idle_optimizations, but works at the\nDMCUB level and makes sure the state is marked prior to any notify/exit\nidle so we don\u0027t enter an infinite loop.\n\n3. Make sure we exit out of idle prior to sending any commands or\n   waiting for DMCUB idle.\n\nThis patch takes care of 1/2. A future patch will take care of wrapping\nDMCUB command submission with calls to this new interface.",
  "id": "GHSA-78r6-645f-335q",
  "modified": "2025-03-17T15:31:36Z",
  "published": "2024-03-26T18:32:06Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52625"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/820c3870c491946a78950cdf961bf40e28c1025f"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/8e57c06bf4b0f51a4d6958e15e1a99c9520d00fa"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…

Loading…