CVE-2024-46705: drm/xe: reset mmio mappings with devm
In the Linux kernel, the following vulnerability has been resolved:
drm/xe: reset mmio mappings with devm
Set our various mmio mappings to NULL. This should make it easier to
catch something rogue trying to mess with mmio after device removal. For
example, we might unmap everything and then start hitting some mmio
address which has already been unmamped by us and then remapped by
something else, causing all kinds of carnage.
Security readout for executives and security teams
Plain-English summary
A Linux Xe graphics driver cleanup flaw can leave stale memory-mapped hardware references after device removal. Later access could affect system confidentiality, integrity, or availability. Exploitation requires local, low-privileged access according to the supplied CVSS assessment.
Executive priority
Treat this as a high-priority kernel maintenance issue where affected Xe graphics functionality and untrusted local users coexist. It is less urgent for systems without the affected driver path. No supplied evidence supports emergency response for active exploitation.
Technical view
The drm/xe driver did not reset several MMIO mapping pointers to NULL when device-managed mappings were released. A later rogue access could target unmapped memory that another component had remapped. The cited kernel changes correct the cleanup behavior; the supplied evidence does not establish a specific resulting primitive.
Likely exposure
Exposure is limited to Linux systems using the affected drm/xe code. The bundle identifies Linux 6.8-era code and cited corrective commits, but its flattened version data is ambiguous. Confirm exposure using the exact kernel commit or distribution backport rather than version numbers alone.
Exploitation context
The CVSS vector describes local access, low privileges, low complexity, and no user interaction, with potentially high confidentiality, integrity, and availability impact. The CVE is not listed as KEV, and the supplied sources provide no evidence of active exploitation or a public exploit.
Researcher notes
The security-relevant condition is stale MMIO pointers surviving device-managed unmapping during removal. Setting them to NULL improves detection and prevents subsequent use. The description warns of access after another mapping occupies the address, but does not document reproducibility, affected hardware, crash signatures, or demonstrated privilege escalation.
Mitigation direction
Install a supported vendor kernel containing the cited stable correction or an equivalent backport.
Check distribution security guidance for the exact fixed package applicable to each system.
Prioritize multi-user or otherwise untrusted-access systems that load the drm/xe driver.
Avoid relying solely on upstream version numbers because distributions commonly backport kernel fixes.
Validation and detection
Inventory kernel versions and determine whether the drm/xe driver is present or loaded.
Map each installed kernel to vendor advisories, package changelogs, or the cited corrective commits.
Confirm replacement kernels are active after maintenance and vulnerable kernels are no longer booted.
Review kernel logs for Xe device-removal faults, treating their absence as non-conclusive.
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-46705 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.