ghsa-p8xh-x6wj-7w7g
Vulnerability from github
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] [ 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
{
"affected": [],
"aliases": [
"CVE-2025-38449"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-07-25T16:15:30Z",
"severity": null
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/gem: Acquire references on GEM handles for framebuffers\n\nA GEM handle can be released while the GEM buffer object is attached\nto a DRM framebuffer. This leads to the release of the dma-buf backing\nthe buffer object, if any. [1] Trying to use the framebuffer in further\nmode-setting operations leads to a segmentation fault. Most easily\nhappens with driver that use shadow planes for vmap-ing the dma-buf\nduring a page flip. An example is shown below.\n\n[ 156.791968] ------------[ cut here ]------------\n[ 156.796830] WARNING: CPU: 2 PID: 2255 at drivers/dma-buf/dma-buf.c:1527 dma_buf_vmap+0x224/0x430\n[...]\n[ 156.942028] RIP: 0010:dma_buf_vmap+0x224/0x430\n[ 157.043420] Call Trace:\n[ 157.045898] \u003cTASK\u003e\n[ 157.048030] ? show_trace_log_lvl+0x1af/0x2c0\n[ 157.052436] ? show_trace_log_lvl+0x1af/0x2c0\n[ 157.056836] ? show_trace_log_lvl+0x1af/0x2c0\n[ 157.061253] ? drm_gem_shmem_vmap+0x74/0x710\n[ 157.065567] ? dma_buf_vmap+0x224/0x430\n[ 157.069446] ? __warn.cold+0x58/0xe4\n[ 157.073061] ? dma_buf_vmap+0x224/0x430\n[ 157.077111] ? report_bug+0x1dd/0x390\n[ 157.080842] ? handle_bug+0x5e/0xa0\n[ 157.084389] ? exc_invalid_op+0x14/0x50\n[ 157.088291] ? asm_exc_invalid_op+0x16/0x20\n[ 157.092548] ? dma_buf_vmap+0x224/0x430\n[ 157.096663] ? dma_resv_get_singleton+0x6d/0x230\n[ 157.101341] ? __pfx_dma_buf_vmap+0x10/0x10\n[ 157.105588] ? __pfx_dma_resv_get_singleton+0x10/0x10\n[ 157.110697] drm_gem_shmem_vmap+0x74/0x710\n[ 157.114866] drm_gem_vmap+0xa9/0x1b0\n[ 157.118763] drm_gem_vmap_unlocked+0x46/0xa0\n[ 157.123086] drm_gem_fb_vmap+0xab/0x300\n[ 157.126979] drm_atomic_helper_prepare_planes.part.0+0x487/0xb10\n[ 157.133032] ? lockdep_init_map_type+0x19d/0x880\n[ 157.137701] drm_atomic_helper_commit+0x13d/0x2e0\n[ 157.142671] ? drm_atomic_nonblocking_commit+0xa0/0x180\n[ 157.147988] drm_mode_atomic_ioctl+0x766/0xe40\n[...]\n[ 157.346424] ---[ end trace 0000000000000000 ]---\n\nAcquiring GEM handles for the framebuffer\u0027s GEM buffer objects prevents\nthis from happening. The framebuffer\u0027s cleanup later puts the handle\nreferences.\n\nCommit 1a148af06000 (\"drm/gem-shmem: Use dma_buf from GEM object\ninstance\") triggers the segmentation fault easily by using the dma-buf\nfield more widely. The underlying issue with reference counting has\nbeen present before.\n\nv2:\n- acquire the handle instead of the BO (Christian)\n- fix comment style (Christian)\n- drop the Fixes tag (Christian)\n- rename err_ gotos\n- add missing Link tag",
"id": "GHSA-p8xh-x6wj-7w7g",
"modified": "2025-07-25T18:30:39Z",
"published": "2025-07-25T18:30:39Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38449"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/08480e285c6a82ce689008d643e4a51db0aaef8b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3cf520d9860d4ec9f7f32068825da31f18dd3f25"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5307dce878d4126e1b375587318955bd019c3741"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cb4c956a15f8b7f870649454771fc3761f504b5f"
}
],
"schema_version": "1.4.0",
"severity": []
}
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
- Confirmed: The vulnerability is confirmed from an analyst perspective.
- Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
- Patched: This vulnerability was successfully patched by the user reporting the sighting.
- Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
- Not confirmed: The user expresses doubt about the veracity of the vulnerability.
- Not patched: This vulnerability was not successfully patched by the user reporting the sighting.