Re: [PATCH v5 1/2] drm/hyperv: validate resolution_count and fix WIN8 fallback

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] State Machine Desynchronization and Type Confusion due to missing reinit_completion()
--

commit 75355159caa20ef4cf6b36266c2aa7dcbac0177d
Author: Berkant Koc <me@berkoc.com>

drm/hyperv: validate resolution_count and fix WIN8 fallback

This commit bounds the resolution_count in SYNTHVID_RESOLUTION_RESPONSE
to avoid out-of-bounds array access. It also adds a unified fallback
for WIN8 default resolutions when the probe fails or max dimensions
are left unpopulated.

> diff --git a/drivers/gpu/drm/hyperv/hyperv_drm_proto.c b/drivers/gpu/drm/hyperv/hyperv_drm_proto.c
> index 051ecc5268321..c3d0ff229e3d0 100644
> --- a/drivers/gpu/drm/hyperv/hyperv_drm_proto.c
> +++ b/drivers/gpu/drm/hyperv/hyperv_drm_proto.c
> @@ -391,8 +391,11 @@ static int hyperv_get_supported_resolution(struct hv_device *hdev)
>  		return -ETIMEDOUT;
>  	}

[Severity: High]
This is a pre-existing issue, but does reusing hv->wait without calling
reinit_completion() risk state machine desynchronization?

If a prior request like hyperv_negotiate_version() times out, a delayed
response could trigger complete(&hv->wait) and leave the completion
signaled. When wait_for_completion_timeout() is called in this function,
would it return immediately without waiting for the actual response?

If a WIN10 version negotiation times out and falls back to WIN8, could a
delayed WIN10 response satisfy the subsequent WIN8 wait, leading the driver
to mistakenly assume the hypervisor agreed to the WIN8 protocol?

Since there is no validation of msg->vid_hdr.type after waking up, could
this lead to type confusion where a delayed response from an earlier
request is incorrectly interpreted as the current response?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1779542874.git.me@berkoc.com?part=1