Re: [PATCH v4 1/3] drm/amd/display: Fix dangling pointer in plane reset function

[Evgenii Burenchev]

On Mon, Jun 29, 2026 at 09:25:37AM +0000, sashiko-bot@xxxxxxxxxx wrote:
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
>
> Pre-existing issues:
> - [High] Dangling pointer (Use-After-Free) vulnerability in vmwgfx component reset hooks on memory allocation failure.
> - [High] Missing NULL pointer checks in amdgpu duplicate_state hooks lead to NULL pointer dereference on allocation failure.

Thank you for the review.

> [Severity: High]
> This is a pre-existing issue, but returning here when plane->state is
> initially NULL means plane->state remains NULL. Later, when the DRM core
> attempts to duplicate the state, it calls the driver's duplicate hook.
>
> In amdgpu_dm_plane_drm_plane_duplicate_state(), there is no check if
> plane->state is NULL:
>
> amdgpu_dm_plane_drm_plane_duplicate_state() {
>     ...
>         dm_plane_state = kzalloc_obj(*dm_plane_state);
>         if (!dm_plane_state)
>                 return NULL;
>
>         __drm_atomic_helper_plane_duplicate_state(plane, &dm_plane_state->base);
>     ...
> }
>
> Will this cause a NULL pointer dereference in
> __drm_atomic_helper_plane_duplicate_state() since it will crash when trying
> to memcpy from a NULL plane->state?

The DRM core guarantees that duplicate_state() is never called on an object
with a NULL state. The state pointer is always valid when duplication is
requested, as DRM only calls this hook on objects that are already fully
initialized and have an active state.

Therefore, the scenario described above is not possible in practice.
This patch does not introduce any new NULL pointer risks.

> The same pattern appears in amdgpu_dm_connector_atomic_duplicate_state(),
> where to_dm_connector_state(connector->state) will resolve to an invalid
> pointer offset from NULL, causing kmemdup to panic:
>
> Could these duplicate_state hooks be updated to handle a NULL state?

As explained above, DRM core guarantees that duplicate_state is only called
with a valid state. Adding NULL checks in duplicate_state hooks would be
redundant and unnecessary.

> [Severity: High]
> This isn't a bug introduced by this patch, but I noticed the exact same
> dangling pointer pattern this patch fixes also exists in the vmwgfx driver.
>
> In vmw_du_connector_reset(), if kzalloc_obj() fails, it returns without
> updating the state pointer, leaving a dangling pointer:
>
> The identical issue also occurs in vmw_du_crtc_reset() and
> vmw_du_plane_reset().
>
> Since unhandled use-after-free bugs in core DRM state structures can cause
> severe stability issues, do these vmwgfx component reset hooks need a similar
> fix to allocate the new state before freeing the old one?

This is a separate pre-existing issue in a different driver (vmwgfx).
While it does appear to suffer from the same dangling pointer pattern,
it is unrelated to this patch series and should be addressed in a
separate patch by the vmwgfx maintainers.

This patch series only addresses the dangling pointer issue in the
amdgpu_dm reset functions.

Signed-off-by: Evgenii Burenchev <evg28bur@xxxxxxxxx>