CVE-2024-35817: drm/amdgpu: amdgpu_ttm_gart_bind set gtt bound flag
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: amdgpu_ttm_gart_bind set gtt bound flag
Otherwise after the GTT bo is released, the GTT and gart space is freed
but amdgpu_ttm_backend_unbind will not clear the gart page table entry
and leave valid mapping entry pointing to the stale system page. Then
if GPU access the gart address mistakely, it will read undefined value
instead page fault, harder to debug and reproduce the real issue.
Security readout for executives and security teams
Plain-English summary
A Linux AMD GPU driver flaw can leave a valid graphics-memory mapping pointing to a stale system page after memory is released. Later accidental GPU access may read undefined data instead of faulting. This can obscure the underlying failure and may affect confidentiality, integrity, or availability under the supplied CVSS assumptions.
Executive priority
Treat this as a high-priority kernel maintenance issue for AMD GPU fleets, especially multi-user or untrusted-workload systems. Prioritize inventory and supported kernel updates, but the current evidence does not justify an active-exploitation emergency response.
Technical view
The amdgpu GTT binding path failed to set the bound state correctly. Consequently, backend unbinding might not clear a GART page-table entry after releasing the GTT buffer object and its address space, leaving a stale mapping. The cited Linux stable commits correct this state-management issue.
Likely exposure
Exposure is most likely on Linux systems running affected kernels with AMD GPUs using the amdgpu driver and GTT/GART memory paths. The supplied version data is not a clean range, so administrators should verify distribution-specific kernel status rather than relying solely on listed numbers.
Exploitation context
The supplied CVSS 3.1 score is 7.8 and assumes local access, low privileges, low complexity, and no user interaction. KEV is false, and the bundle provides no evidence of active exploitation or a public exploit. Practical exploitability and security impact beyond undefined GPU reads remain unclear.
Researcher notes
The record describes stale GART mapping caused by incorrect GTT bound-state handling. No CWE is supplied. The affected-version data contains duplicate commit entries and ambiguous version points, limiting exact range conclusions. The sources establish upstream fixes but do not demonstrate exploitation, reliable triggering, or observed attacks.
Mitigation direction
Install a vendor-supported Linux kernel incorporating the applicable cited stable fix.
Follow the Linux distributor's security guidance when mapping packaged kernel versions to upstream fixes.
If patching is delayed, restrict local access to affected AMD GPU systems.
Reboot after updating so the corrected kernel and driver are active.
Validation and detection
Inventory systems with AMD GPUs and determine whether the amdgpu driver is loaded.
Record each running kernel version and compare it with distributor advisories and applicable stable commits.
Confirm the updated kernel contains the relevant fix, then verify that kernel is running.
Review kernel and GPU logs, while recognizing that absent errors do not prove safety.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2024-35817 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.