In the Linux kernel, the following vulnerability has been resolved:
drm/i915: Fix request ref counting during error capture & debugfs dump
When GuC support was added to error capture, the reference counting
around the request object was broken. Fix it up.
The context based search manages the spinlocking around the search
internally. So it needs to grab the reference count internally as
well. The execlist only request based search relies on external
locking, so it needs an external reference count but within the
spinlock not outside it.
The only other caller of the context based search is the code for
dumping engine state to debugfs. That code wasn't previously getting
an explicit reference at all as it does everything while holding the
execlist specific spinlock. So, that needs updaing as well as that
spinlock doesn't help when using GuC submission. Rather than trying to
conditionally get/put depending on submission model, just change it to
always do the get/put.
v2: Explicitly document adding an extra blank line in some dense code
(Andy Shevchenko). Fix multiple potential null pointer derefs in case
of no request found (some spotted by Tvrtko, but there was more!).
Also fix a leaked request in case of !started and another in
__guc_reset_context now that intel_context_find_active_request is
actually reference counting the returned request.
v3: Add a _get suffix to intel_context_find_active_request now that it
grabs a reference (Daniele).
v4: Split the intel_guc_find_hung_context change to a separate patch
and rename intel_context_find_active_request_get to
intel_context_get_active_request (Tvrtko).
v5: s/locking/reference counting/ in commit message (Tvrtko)
(cherry picked from commit 3700e353781e27f1bc7222f51f2cc36cbeb9b4ec)
Security readout for executives and security teams
Plain-English summary
CVE-2023-52981 is a Linux kernel i915 graphics driver flaw involving incorrect request reference counting during error capture and debugfs engine dumps. It is rated high because a local low-privileged user could potentially impact confidentiality, integrity, and availability on affected systems.
Executive priority
Treat as a high-priority routine kernel update, not an emergency internet-facing incident. Focus first on multi-user Linux systems and Intel graphics endpoints. No provided source supports active exploitation.
Technical view
The issue is in drm/i915 request object lifetime handling after GuC error capture support. The fix adjusts reference acquisition and release around active-request searches, debugfs engine-state dumping, and related null/leak paths. CVSS is 7.8: local attack vector, low complexity, low privileges, no user interaction.
Likely exposure
Most relevant to Linux systems running affected kernels with Intel i915 graphics support, especially where GuC submission or i915 debug/error capture paths are present. Systems without the i915 driver loaded are likely less exposed, but confirm with vendor kernel guidance.
Exploitation context
The CVE record does not indicate known active exploitation, and it is not listed as CISA KEV in the provided bundle. Exploitation is local, requiring low privileges, so shared workstations, developer systems, kiosks, and multi-user Linux hosts deserve attention.
Researcher notes
Affected-version detail in the bundle is limited and somewhat patch-centric. The strongest evidence is the kernel commit description describing broken reference counting, null dereference fixes, and request leaks. Validate exposure against downstream distribution advisories and backported kernel patches.
Mitigation direction
Apply Linux distribution kernel updates that include the referenced stable fixes.
Prioritize systems with Intel i915 graphics enabled or multi-user local access.
If no update is available, monitor your Linux vendor guidance for backports.
Limit unnecessary local user access on affected systems until updated.
Validation and detection
Inventory Linux kernel versions across endpoints and servers.
Check whether the i915 driver is present or loaded.
Review vendor changelogs for the referenced stable commit IDs.
Confirm patched kernels are installed and active after reboot.
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-2023-52981 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.
1CVSS vectors
3Timeline events
0ADP providers
3Source links
CVSS vector scores
1 official score
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.