All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Thomas Zimmermann" <tzimmermann@suse.de>
Cc: linux-hyperv@vger.kernel.org
Subject: Re: [PATCH v4 02/10] drm/atomic-helpers: Evaluate plane damage after atomic_check
Date: Sat, 30 May 2026 19:08:56 +0000	[thread overview]
Message-ID: <20260530190856.E587F1F00893@smtp.kernel.org> (raw)
In-Reply-To: <20260530185716.65688-3-tzimmermann@suse.de>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Modifying `ignore_damage_clips` after `plane->atomic_check` runs invalidates resource allocations based on partial damage clips, leading to heap buffer overflows.
--

commit 395f91f063087b27412023cba7e5d824633a9392
Author: Thomas Zimmermann <tzimmermann@suse.de>

drm/atomic-helpers: Evaluate plane damage after atomic_check

This commit evaluates damage clips after running the atomic_check helpers.
It adds a loop calling drm_atomic_helper_check_plane_damage() after the
driver's plane and CRTC atomic_check hooks have executed. This allows the
damage handling to account for full modesets triggered by the check hooks.

> diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c
> index 51f39edc31edc..4c37299e8ccb7 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
[ ... ]
> @@ -1065,6 +1065,10 @@ drm_atomic_helper_check_planes(struct drm_device *dev,
>  		}
>  	}
>  
> +	for_each_oldnew_plane_in_state(state, plane, old_plane_state, new_plane_state, i) {
> +		drm_atomic_helper_check_plane_damage(state, new_plane_state);
> +	}
> +

[Severity: High]
Does modifying ignore_damage_clips after plane->atomic_check has already
run invalidate resource allocations in drivers that use partial damage clips?

For example, in drivers/gpu/drm/tiny/appletbdrm.c:appletbdrm_primary_plane_helper_atomic_check(),
the driver sizes a buffer precisely to the damage clips evaluated during
atomic_check:

	drm_atomic_helper_damage_iter_init(&iter, old_plane_state, new_plane_state);
	drm_atomic_for_each_plane_damage(&iter, &damage) {
		frames_size += struct_size((struct appletbdrm_frame *)0, buf, rect_size(&damage));
	}
	...
	appletbdrm_state->request = kvzalloc(request_size, GFP_KERNEL);

If a modeset is triggered during the check hooks and this second loop sets
ignore_damage_clips to true, won't drm_atomic_helper_damage_iter_init() later
return a full-screen damage clip during atomic_update? Could this cause the
driver to copy full-screen damage into the buffer allocated only for partial
damage, resulting in a heap buffer overflow?

I understand this is explicitly acknowledged and fixed later in the patch
series by commit 72afced3e1b6baa294269874c7c4d9d05230889c ('drm/appletbdrm:
Allocate request/response buffers in begin_fb_access').

>  	return ret;
>  }
>  EXPORT_SYMBOL(drm_atomic_helper_check_planes);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260530185716.65688-1-tzimmermann@suse.de?part=2

  reply	other threads:[~2026-05-30 19:08 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-30 18:53 [PATCH v4 00/10] drm: Improve logic behind damage handling Thomas Zimmermann
2026-05-30 18:53 ` [PATCH v4 01/10] drm/damage-helper: Do not alter damage clips on modeset, but ignore them Thomas Zimmermann
2026-05-30 19:10   ` sashiko-bot
2026-06-01 10:16   ` Javier Martinez Canillas
2026-05-30 18:53 ` [PATCH v4 02/10] drm/atomic-helpers: Evaluate plane damage after atomic_check Thomas Zimmermann
2026-05-30 19:08   ` sashiko-bot [this message]
2026-06-01 10:19   ` Javier Martinez Canillas
2026-05-30 18:53 ` [PATCH v4 03/10] drm/ingenic: Remove calls to drm_atomic_helper_check_plane_damage() Thomas Zimmermann
2026-05-30 19:05   ` sashiko-bot
2026-06-01 10:20   ` Javier Martinez Canillas
2026-05-30 18:53 ` [PATCH v4 04/10] drm/appletbdrm: Allocate request/response buffers in begin_fb_access Thomas Zimmermann
2026-05-30 19:09   ` sashiko-bot
2026-06-01 10:21   ` Javier Martinez Canillas
2026-05-30 18:53 ` [PATCH v4 05/10] drm/atomic_helper: Do not evaluate plane damage before atomic_check Thomas Zimmermann
2026-06-01 10:22   ` Javier Martinez Canillas
2026-05-30 18:53 ` [PATCH v4 06/10] drm/damage-helper: Test src coord in drm_atomic_helper_check_plane_damage() Thomas Zimmermann
2026-05-30 19:09   ` sashiko-bot
2026-06-01 10:27   ` Javier Martinez Canillas
2026-05-30 18:53 ` [PATCH v4 07/10] drm/damage-helper: Remove old state from drm_atomic_helper_damage_iter_init() Thomas Zimmermann
2026-06-01 10:28   ` Javier Martinez Canillas
2026-06-01 14:01   ` Hamza Mahfooz
2026-05-30 18:53 ` [PATCH v4 08/10] drm/damage-helper: Remove old state from drm_atomic_helper_damage_merged() Thomas Zimmermann
2026-05-30 19:16   ` sashiko-bot
2026-06-01 10:29   ` Javier Martinez Canillas
2026-05-30 18:53 ` [PATCH v4 09/10] drm/damage-helper: Rename state parameters in damage helpers Thomas Zimmermann
2026-06-01 10:29   ` Javier Martinez Canillas
2026-05-30 18:53 ` [PATCH v4 10/10] drm/vmwgfx: Remove unused field struct vmwgfx_du_update_plane.old_state Thomas Zimmermann
2026-06-01 10:30   ` Javier Martinez Canillas
2026-05-30 19:19 ` ✗ Fi.CI.BUILD: failure for drm: Improve logic behind damage handling (rev3) Patchwork

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260530190856.E587F1F00893@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=linux-hyperv@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=tzimmermann@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.