[lts9_4] CVE-2025-38449 #653
Conversation
jira VULN-136708 cve CVE-2025-38449 commit-author Thomas Zimmermann <[email protected]> commit 5307dce 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 1a148af ("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 Suggested-by: Christian König <[email protected]> Signed-off-by: Thomas Zimmermann <[email protected]> Link: https://elixir.bootlin.com/linux/v6.15/source/drivers/gpu/drm/drm_gem.c#L241 # [1] Cc: Thomas Zimmermann <[email protected]> Cc: Anusha Srivatsa <[email protected]> Cc: Christian König <[email protected]> Cc: Maarten Lankhorst <[email protected]> Cc: Maxime Ripard <[email protected]> Cc: Sumit Semwal <[email protected]> Cc: "Christian König" <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: <[email protected]> Reviewed-by: Christian König <[email protected]> Link: https://lore.kernel.org/r/[email protected] (cherry picked from commit 5307dce) Signed-off-by: Roxana Nicolescu <[email protected]>
There was a problem hiding this comment.
Note: If you check compare the diff for the last commit
("drm/framebuffer: Acquire internal references on GEM handles") with
a bigger context, you'll notice a difference in drm_framebuffer_init
function. See below. This is because this commit is missing.
3240aad ("drm: replace strcpy() with strscpy()").
I did not cherry-picked it because it is not relevant to this CVE, even
though it's a security fix. Let me know if you think otherwise.
This is fine we can leave this out, searching its not a CVE but it is safer code.
I would like @kerneltoast to look this over as well just in case as he has more expierence with drm than many.
There was a problem hiding this comment.
From 4a622d7 (drm/atomic: Add support for mouse hotspots):
Due to the lack of hotspots in the atomic paths userspace compositors
completely disable atomic modesetting for drivers that require it (i.e.
all paravirtualized drivers).This change adds hotspot properties to the atomic codepaths throughtout
the DRM core and will allow enabling atomic modesetting for virtualized
drivers in the userspace.
This is a big change that may result in userspace making incorrect assumptions about the capabilities of a kms driver because the cursor feature patchset wasn't backported fully (explained below) and because there may be additional necessary commits for fixing atomic modesetting bugs exposed by userspace's switch to using atomic modesetting as a result of these changes.
If you follow the patchwork link in one of the cursor commits, you can find the full patchset: https://patchwork.freedesktop.org/series/125453/
And some of those patches (which look necessary) weren't backported here.
I tried cherry-picking drm/framebuffer: Acquire internal references on GEM handles right after drm/gem: Acquire references on GEM handles for framebuffers without any of the cursor-related commits, and there is just one trivial conflict for placement of a new member into struct drm_framebuffer:
+++ b/include/drm/drm_framebuffer.h
@@@ -189,17 -192,9 +192,23 @@@ struct drm_framebuffer
*/
int flags;
/**
++<<<<<<< HEAD
+ * @hot_x: X coordinate of the cursor hotspot. Used by the legacy cursor
+ * IOCTL when the driver supports cursor through a DRM_PLANE_TYPE_CURSOR
+ * universal plane.
+ */
+ int hot_x;
+ /**
+ * @hot_y: Y coordinate of the cursor hotspot. Used by the legacy cursor
+ * IOCTL when the driver supports cursor through a DRM_PLANE_TYPE_CURSOR
+ * universal plane.
+ */
+ int hot_y;
++=======
+ * @internal_flags: Framebuffer flags like DRM_FRAMEBUFFER_HAS_HANDLE_REF.
+ */
+ unsigned int internal_flags;
++>>>>>>> f6bfc9afc7510 (drm/framebuffer: Acquire internal references on GEM handles)
/**
* @filp_head: Placed on &drm_file.fbs, protected by &drm_file.fbs_lock.
*/@bmastbergen had this conflict picking the same commit onto 9.2 actually.
Just resolve the conflict the same way as linked above by placing unsigned int internal_flags; right after int flags;, and then drop all of the cursor commits.
jira VULN-136708 cve-bf CVE-2025-38449 commit-author Thomas Zimmermann <[email protected]> commit f6bfc9a upstream-diff | Manually solved the conflict in 'struct drm_framebuffer' due to variables 'hot_x' and 'hot_y' still being there (removed in commit "drm: Remove legacy cursor hotspot code"). This is part of a bigger patchset that refactors atomic modesetting that should not be backported due the impact of the changes. Acquire GEM handles in drm_framebuffer_init() and release them in the corresponding drm_framebuffer_cleanup(). Ties the handle's lifetime to the framebuffer. Not all GEM buffer objects have GEM handles. If not set, no refcounting takes place. This is the case for some fbdev emulation. This is not a problem as these GEM objects do not use dma-bufs and drivers will not release them while fbdev emulation is running. Framebuffer flags keep a bit per color plane of which the framebuffer holds a GEM handle reference. As all drivers use drm_framebuffer_init(), they will now all hold dma-buf references as fixed in commit 5307dce ("drm/gem: Acquire references on GEM handles for framebuffers"). In the GEM framebuffer helpers, restore the original ref counting on buffer objects. As the helpers for handle refcounting are now no longer called from outside the DRM core, unexport the symbols. v3: - don't mix internal flags with mode flags (Christian) v2: - track framebuffer handle refs by flag - drop gma500 cleanup (Christian) Signed-off-by: Thomas Zimmermann <[email protected]> Fixes: 5307dce ("drm/gem: Acquire references on GEM handles for framebuffers") Reported-by: Bert Karwatzki <[email protected]> Closes: https://lore.kernel.org/dri-devel/[email protected]/ Tested-by: Bert Karwatzki <[email protected]> Tested-by: Mario Limonciello <[email protected]> Tested-by: Borislav Petkov (AMD) <[email protected]> Cc: Thomas Zimmermann <[email protected]> Cc: Anusha Srivatsa <[email protected]> Cc: Christian König <[email protected]> Cc: Maarten Lankhorst <[email protected]> Cc: Maxime Ripard <[email protected]> Cc: Sumit Semwal <[email protected]> Cc: "Christian König" <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: <[email protected]> Reviewed-by: Christian König <[email protected]> Link: https://lore.kernel.org/r/[email protected] (cherry picked from commit f6bfc9a) Signed-off-by: Roxana Nicolescu <[email protected]> Signed-off-by: Roxana Nicolescu <[email protected]>
roxanan1996
dismissed stale reviews from PlaidCat and bmastbergen
via
9b58ac7
roxanan1996
force-pushed
the
{rnicolescu}_ciqlts9_4
branch
from
46fefa9 to
9b58ac7
Compare
DESCRIPTION
is the CVE fix, clean cherry pick.
The second is a Fixed-by ref. Not a clean cherry-pick, I manually
solved the conflict in
struct drm_framebuffer.COMMITS
TESTING
BUILD
kernel-build-before.log
kernel-build-after.log
Kselftests
kselftest-before.log
kselftest-after.log
Check_kernel_commits including interdiff