Re: [PATCH v5 1/2] drm/hyperv: validate resolution_count and fix WIN8 fallback
From: sashiko-bot@kernel.org
Date: 2026-05-23 14:37:22
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 [off-list ref] 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.
quoted hunk ↗ jump to hunk
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