CVE-2024-46683: drm/xe: prevent UAF around preempt fence
In the Linux kernel, the following vulnerability has been resolved:
drm/xe: prevent UAF around preempt fence
The fence lock is part of the queue, therefore in the current design
anything locking the fence should then also hold a ref to the queue to
prevent the queue from being freed.
However, currently it looks like we signal the fence and then drop the
queue ref, but if something is waiting on the fence, the waiter is
kicked to wake up at some later point, where upon waking up it first
grabs the lock before checking the fence state. But if we have already
dropped the queue ref, then the lock might already be freed as part of
the queue, leading to uaf.
To prevent this, move the fence lock into the fence itself so we don't
run into lifetime issues. Alternative might be to have device level
lock, or only release the queue in the fence release callback, however
that might require pushing to another worker to avoid locking issues.
References: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/2454
References: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/2342
References: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/2020
(cherry picked from commit 7116c35aacedc38be6d15bd21b2fc936eed0008b)
Security readout for executives and security teams
Plain-English summary
A lifetime-management flaw in Linux’s drm/xe graphics driver can leave software accessing a queue lock after its memory is freed. A low-privileged local user may be able to trigger serious confidentiality, integrity, or availability impacts. The supplied evidence does not establish remote reachability or exploitation in the wild.
Executive priority
Treat this as a high-priority kernel maintenance issue on multi-user or otherwise untrusted systems using drm/xe. It is not evidenced as an internet-scale emergency, but local low-privileged access and potentially complete impact justify prompt validation and patching.
Technical view
The preemption fence lock was stored inside its queue. After signaling the fence, the queue reference could be released before a waiting task awakened and acquired that lock, producing a use-after-free. The cited kernel fixes move the lock into the fence so its lifetime follows the waiting operation.
Likely exposure
Exposure is limited to systems running an affected Linux kernel and using the drm/xe driver path. The CVSS vector requires local access and low privileges, with no user interaction. The bundle’s version data is ambiguous, so distributions and backports must be checked against the cited fix commits.
Exploitation context
CISA KEV status is false in the supplied bundle, and no cited source reports active exploitation or a public exploit. The 7.8 CVSS score reflects potentially severe local impact, but practical exploitability and reliability are not established by the available evidence.
Researcher notes
The vulnerable sequence is a race between fence signaling, queue-reference release, waiter wake-up, and lock acquisition. Moving the lock into the fence corrects the lifetime mismatch. The supplied record provides no CWE, proof of exploitation, triggering reliability data, or sufficiently clear version-range semantics; validate exposure using commit-level vendor evidence.
Mitigation direction
Install a vendor-supported kernel containing the cited stable fix or an equivalent backport.
Prioritize shared systems where untrusted or low-privileged users can access affected graphics functionality.
Check distribution security advisories because packaged kernel versions may contain backported fixes.
If immediate updating is impossible, consult vendor guidance for supported exposure-reduction measures.
Validation and detection
Inventory deployed kernel versions and identify systems using the drm/xe driver.
Compare vendor kernel changelogs against both cited stable fix commits.
Confirm the updated kernel is running after remediation, not merely installed.
Reassess local account and workload access on systems awaiting remediation.
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-46683 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.