CVE-2025-38449: drm/gem: Acquire references on GEM handles for framebuffers
In the Linux kernel, the following vulnerability has been resolved:
drm/gem: Acquire references on GEM handles for framebuffers
A GEM handle can be released while the GEM buffer object is attached
to a DRM framebuffer. This leads to the release of the dma-buf backing
the buffer object, if any. [1] Trying to use the framebuffer in further
mode-setting operations leads to a segmentation fault. Most easily
happens with driver that use shadow planes for vmap-ing the dma-buf
during a page flip. An example is shown below.
[ 156.791968] ------------[ cut here ]------------
[ 156.796830] WARNING: CPU: 2 PID: 2255 at drivers/dma-buf/dma-buf.c:1527 dma_buf_vmap+0x224/0x430
[...]
[ 156.942028] RIP: 0010:dma_buf_vmap+0x224/0x430
[ 157.043420] Call Trace:
[ 157.045898] <TASK>
[ 157.048030] ? show_trace_log_lvl+0x1af/0x2c0
[ 157.052436] ? show_trace_log_lvl+0x1af/0x2c0
[ 157.056836] ? show_trace_log_lvl+0x1af/0x2c0
[ 157.061253] ? drm_gem_shmem_vmap+0x74/0x710
[ 157.065567] ? dma_buf_vmap+0x224/0x430
[ 157.069446] ? __warn.cold+0x58/0xe4
[ 157.073061] ? dma_buf_vmap+0x224/0x430
[ 157.077111] ? report_bug+0x1dd/0x390
[ 157.080842] ? handle_bug+0x5e/0xa0
[ 157.084389] ? exc_invalid_op+0x14/0x50
[ 157.088291] ? asm_exc_invalid_op+0x16/0x20
[ 157.092548] ? dma_buf_vmap+0x224/0x430
[ 157.096663] ? dma_resv_get_singleton+0x6d/0x230
[ 157.101341] ? __pfx_dma_buf_vmap+0x10/0x10
[ 157.105588] ? __pfx_dma_resv_get_singleton+0x10/0x10
[ 157.110697] drm_gem_shmem_vmap+0x74/0x710
[ 157.114866] drm_gem_vmap+0xa9/0x1b0
[ 157.118763] drm_gem_vmap_unlocked+0x46/0xa0
[ 157.123086] drm_gem_fb_vmap+0xab/0x300
[ 157.126979] drm_atomic_helper_prepare_planes.part.0+0x487/0xb10
[ 157.133032] ? lockdep_init_map_type+0x19d/0x880
[ 157.137701] drm_atomic_helper_commit+0x13d/0x2e0
[ 157.142671] ? drm_atomic_nonblocking_commit+0xa0/0x180
[ 157.147988] drm_mode_atomic_ioctl+0x766/0xe40
[...]
[ 157.346424] ---[ end trace 0000000000000000 ]---
Acquiring GEM handles for the framebuffer's GEM buffer objects prevents
this from happening. The framebuffer's cleanup later puts the handle
references.
Commit 1a148af06000 ("drm/gem-shmem: Use dma_buf from GEM object
instance") triggers the segmentation fault easily by using the dma-buf
field more widely. The underlying issue with reference counting has
been present before.
v2:
- acquire the handle instead of the BO (Christian)
- fix comment style (Christian)
- drop the Fixes tag (Christian)
- rename err_ gotos
- add missing Link tag
Security readout for executives and security teams
Plain-English summary
A Linux graphics reference-counting flaw can release memory backing a framebuffer while it remains in use. Later display operations may access the released object and crash. Exploitation requires local, low-privileged access; no user interaction is required. The record scores it 7.8 High, but the supplied evidence does not establish remote exploitation or privilege escalation.
Executive priority
Treat this as a high-priority local kernel issue on systems with graphics access shared across trust boundaries. Patch promptly through supported distribution channels, especially on multi-user endpoints and graphical infrastructure. Emergency internet-edge action is not supported by the evidence because the attack vector is local and active exploitation is not reported.
Technical view
DRM framebuffer creation did not retain references to associated GEM handles. Releasing a handle could consequently free its dma-buf while the framebuffer still referenced it, producing a use-after-release condition during later mode-setting or page-flip operations. The documented failure is a segmentation fault in dma_buf_vmap. The fix acquires GEM-handle references and releases them during framebuffer cleanup.
Likely exposure
Exposure is concentrated on Linux systems running affected kernels where local users or processes can access DRM framebuffer and mode-setting interfaces. Drivers using shadow planes to vmap dma-bufs during page flips are highlighted as an easy trigger. Headless systems or environments denying untrusted DRM access may have lower practical exposure, but the supplied sources do not define complete driver-specific scope.
Exploitation context
The CVSS vector indicates local access, low complexity, low privileges, and no user interaction. CISA KEV status is false in the supplied record, and no cited source reports active exploitation. The evidence demonstrates a graphics-path segmentation fault; it does not confirm reliable privilege escalation, data theft, or remote attack capability.
Researcher notes
The underlying reference-counting defect predates commit 1a148af06000; that change reportedly makes the fault easier to trigger by using the dma-buf field more broadly. Four stable-kernel commits are cited, suggesting branch-specific backports. The supplied version list is ambiguous and includes an unexplained โ0,โ so distribution advisories and commit ancestry should govern exposure decisions.
Mitigation direction
Install a vendor-supported kernel containing the applicable referenced stable fix.
Reboot into the updated kernel and confirm the previous kernel is no longer active.
Prioritize multi-user workstations, graphical servers, kiosks, and systems exposing DRM devices to untrusted processes.
Until patched, restrict unnecessary untrusted access to DRM device interfaces where operationally feasible.
Consult the Linux distribution advisory for exact package versions and backport status.
Validation and detection
Inventory running kernel versions and compare them with distribution-specific affected and fixed package guidance.
Verify the installed kernel includes the applicable referenced GEM framebuffer fix.
Confirm systems rebooted into the remediated kernel after package installation.
Review kernel logs for dma_buf_vmap warnings, DRM faults, or crashes during mode-setting operations.
Check permissions and container device mappings for unnecessary exposure of DRM devices.
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-2025-38449 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
5Source 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.