CVE-2023-53378: drm/i915/dpt: Treat the DPT BO as a framebuffer
In the Linux kernel, the following vulnerability has been resolved:
drm/i915/dpt: Treat the DPT BO as a framebuffer
Currently i915_gem_object_is_framebuffer() doesn't treat the
BO containing the framebuffer's DPT as a framebuffer itself.
This means eg. that the shrinker can evict the DPT BO while
leaving the actual FB BO bound, when the DPT is allocated
from regular shmem.
That causes an immediate oops during hibernate as we
try to rewrite the PTEs inside the already evicted
DPT obj.
TODO: presumably this might also be the reason for the
DPT related display faults under heavy memory pressure,
but I'm still not sure how that would happen as the object
should be pinned by intel_dpt_pin() while in active use by
the display engine...
(cherry picked from commit 779cb5ba64ec7df80675a956c9022929514f517a)
Security readout for executives and security teams
Plain-English summary
This is a Linux kernel reliability flaw in the Intel i915 graphics driver. Under certain memory-management conditions, especially hibernation, the kernel can crash. The impact is denial of service, not data theft or remote compromise based on the provided sources.
Executive priority
Treat as a routine but real stability update. Prioritize fleets where unexpected crashes during hibernation would disrupt users or operations. It does not indicate known active exploitation or confidentiality risk from the provided evidence.
Technical view
The i915 driver did not treat the DPT buffer object as part of the framebuffer. The memory shrinker could evict that DPT object while the framebuffer stayed bound, causing a kernel oops when hibernation rewrote PTEs. CVSS is 5.5: local access, low complexity, low privileges, availability impact only.
Likely exposure
Exposure is most relevant to Linux systems using Intel i915 graphics on affected kernel versions listed by the CVE record, including 6.0, 6.1.23, 6.2.10, and 6.3. Distribution backports may change practical exposure.
Exploitation context
The provided sources do not show active exploitation, and CISA KEV status is false. The described failure is local and availability-focused, with hibernation identified as a trigger. No remote attack path is described in the sources.
Researcher notes
Evidence is limited to the CVE record and kernel stable commits. The vulnerability is a kernel oops from framebuffer/DPT buffer lifetime handling in drm/i915. The source notes possible display faults under heavy memory pressure but does not confirm that path.
Mitigation direction
Update to a vendor kernel containing the referenced upstream stable fixes.
Check Linux distribution advisories and package changelogs for CVE-2023-53378.
Prioritize affected laptops or workstations using Intel i915 graphics and hibernation.
If unpatched, avoid hibernation on affected systems where operationally feasible.
Validation and detection
Inventory Linux kernel versions and Intel i915 graphics usage.
Compare installed kernels with vendor advisories for CVE-2023-53378.
Review kernel package changelogs for the referenced stable commits.
Confirm no unexplained kernel oops events occur during controlled hibernation testing.
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-53378 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.