CVE-2023-53378
published 2025-09-18CVE-2023-53378: 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()…
PriorityP417medium5.5CVSS 3.1
AVLACLPRLUINSUCNINAH
EPSS
0.14%
3.9th percentile
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)
Affected
14 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| debian | linux | < linux 6.1.25-1 (bookworm) | linux 6.1.25-1 (bookworm) |
| linux | linux | — | — |
| linux | linux | >= 0dc987b699ce4266450d407d6d79d41eab88c5d0 < c781c107731fc09ce4330c8c636b8446d0f72aa4 | c781c107731fc09ce4330c8c636b8446d0f72aa4 |
| linux | linux | >= 0dc987b699ce4266450d407d6d79d41eab88c5d0 < 5390a02b4508416b9bee96674f141c68f89bafbc | 5390a02b4508416b9bee96674f141c68f89bafbc |
| linux | linux | >= 0dc987b699ce4266450d407d6d79d41eab88c5d0 < 3413881e1ecc3cba722a2e87ec099692eed5be28 | 3413881e1ecc3cba722a2e87ec099692eed5be28 |
| linux | linux_kernel | — | — |
| linux | linux_kernel | — | — |
| linux | linux_kernel | — | — |
| linux | linux_kernel | — | — |
| linux | linux_kernel | >= 0 < 6.1.25-1 | 6.1.25-1 |
| linux | linux_kernel | >= 0 < 6.1.25-1 | 6.1.25-1 |
| linux | linux_kernel | >= 0 < 6.1.25-1 | 6.1.25-1 |
| linux | linux_kernel | >= 6.0 < 6.1.23 | 6.1.23 |
| linux | linux_kernel | >= 6.2 < 6.2.10 | 6.2.10 |
CVSS provenance
nvdv3.15.5MEDIUMCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
osv5.5MEDIUM
vendor_debian5.5MEDIUM
vendor_redhat5.5MEDIUM
Stop checking back — get the weekly exploitation signal.
Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.
OSV
CVE-2023-53378: 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_frame
osv·2025-09-18·CVSS 5.5
CVE-2023-53378 [MEDIUM] CVE-2023-53378: 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_frame
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 779cb5ba64ec7df80675a956c90229295
GHSA
GHSA-53wx-c6fx-gwfp: 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_fra
ghsa_unreviewed·2025-09-18
CVE-2023-53378 [MEDIUM] GHSA-53wx-c6fx-gwfp: 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_fra
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 779cb5ba64ec7df80675a956c902
Red Hat
kernel: drm/i915/dpt: Treat the DPT BO as a framebuffer
vendor_redhat·2025-09-18·CVSS 5.5
CVE-2023-53378 [MEDIUM] kernel: drm/i915/dpt: Treat the DPT BO as a framebuffer
kernel: 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...
(ch
Debian
CVE-2023-53378: linux - In the Linux kernel, the following vulnerability has been resolved: drm/i915/dp...
vendor_debian·2023·CVSS 5.5
CVE-2023-53378 [MEDIUM] CVE-2023-53378: linux - In the Linux kernel, the following vulnerability has been resolved: drm/i915/dp...
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 779cb5ba64ec7df80675a956c90229295
No detection rules found.
No public exploits indexed.
2025-09-18
Published