drm/hyperv: harden VMBus message parser input validation

The hyperv synthetic video driver parses VMBus messages from the host without bounding two host-controlled values that feed into fixed-size buffers. Both items are input validation, not security bugs: the Hyper-V host sits inside the trusted compute base under the default Hyper-V threat-model. The patches still trim the inputs the driver accepts at face value, matching the trajectory drivers/hv/ has followed for Confidential-VMBus work where the host is no longer fully trusted.

Patch 1 bounds resolution_count against supported_resolution[SYNTHVID_MAX_RESOLUTION_COUNT]; the existing default_resolution_index check is bypassable when both values exceed 64.

Patch 2 forwards bytes_recvd from vmbus_recvpacket() into the sub-handler so that vid_hdr.type and feature_chg.is_dirt_needed are only read once the host actually delivered enough bytes, and so that the init_buf memcpy uses the received length.

Sending as a plain patch series, not a security disclosure. Compile-tested against drm-fixes (6916d5703ddf), static-only.

Berkant Koc (2):
drm/hyperv: validate resolution_count from host VMBus message drm/hyperv: validate VMBus packet size in receive callback

 drivers/gpu/drm/hyperv/hyperv_drm_proto.c | 22 +++++++++++++++++-----
 1 file changed, 17 insertions(+), 5 deletions(-)

base-commit: 6916d5703ddf9a38f1f6c2cc793381a24ee914c6

2.47.3

The synthetic video device receives a SYNTHVID_RESOLUTION_RESPONSE containing a u8 resolution_count and a u8 default_resolution_index from the host. The existing check rejects resolution_count == 0 and rejects an index that is greater or equal to resolution_count, but does not bound resolution_count itself against the fixed supported_resolution[SYNTHVID_MAX_RESOLUTION_COUNT] array. A host that returns resolution_count > 64 together with an in-range default_resolution_index causes the subsequent loop to read past the array.

Reject any resolution_count that exceeds SYNTHVID_MAX_RESOLUTION_COUNT, folded into the existing zero-check for one log entry per failure. This matches the input-validation pattern used by other VMBus parsers under drivers/hv/ and trims one host-controlled value from the trusted path.

---
 drivers/gpu/drm/hyperv/hyperv_drm_proto.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

index 051ecc526832..003bb118d64c 100644
@@ -391,8 +391,11 @@ static int hyperv_get_supported_resolution(struct hv_device *hdev)
 		return -ETIMEDOUT;
 	}
 
-	if (msg->resolution_resp.resolution_count == 0) {
-		drm_err(dev, "No supported resolutions\n");
+	if (msg->resolution_resp.resolution_count == 0 ||
+	    msg->resolution_resp.resolution_count >
+	    SYNTHVID_MAX_RESOLUTION_COUNT) {
+		drm_err(dev, "Invalid resolution count: %d\n",
+			msg->resolution_resp.resolution_count);
 		return -ENODEV;
 	}
 

2.47.3

hyperv_receive() reads bytes_recvd from vmbus_recvpacket() but does not forward that value to hyperv_receive_sub(). The sub-handler reads msg->vid_hdr.type and msg->feature_chg.is_dirt_needed without knowing how many bytes the host actually wrote, so a short packet leaves the parser reading bytes that the host did not write in this packet. The unconditional memcpy(hv->init_buf, msg, VMBUS_MAX_PACKET_SIZE) on the wait-completion path also copies the full 16 KiB recv_buf regardless of bytes_recvd, including any residue from the prior message.

Pass bytes_recvd into hyperv_receive_sub() and reject any packet shorter than the pipe + synthvid header. The dirt-feature branch additionally requires the feature_change payload size before reading is_dirt_needed. The init_buf copy now uses bytes_recvd as the length argument, which keeps it bounded by VMBUS_MAX_PACKET_SIZE through the new upper check.

---
 drivers/gpu/drm/hyperv/hyperv_drm_proto.c | 15 ++++++++++++---
 1 file changed, 12 insertions(+), 3 deletions(-)

index 003bb118d64c..0d32d9944c43 100644
@@ -420,26 +420,35 @@ static int hyperv_get_supported_resolution(struct hv_device *hdev)
 	return 0;
 }
 
-static void hyperv_receive_sub(struct hv_device *hdev)
+static void hyperv_receive_sub(struct hv_device *hdev, u32 bytes_recvd)
 {
 	struct hyperv_drm_device *hv = hv_get_drvdata(hdev);
 	struct synthvid_msg *msg;
+	size_t hdr_size;
 
 	if (!hv)
 		return;
 
+	hdr_size = sizeof(struct pipe_msg_hdr) +
+		   sizeof(struct synthvid_msg_hdr);
+	if (bytes_recvd < hdr_size || bytes_recvd > VMBUS_MAX_PACKET_SIZE)
+		return;
+
 	msg = (struct synthvid_msg *)hv->recv_buf;
 
 	/* Complete the wait event */
 	if (msg->vid_hdr.type == SYNTHVID_VERSION_RESPONSE ||
 	    msg->vid_hdr.type == SYNTHVID_RESOLUTION_RESPONSE ||
 	    msg->vid_hdr.type == SYNTHVID_VRAM_LOCATION_ACK) {
-		memcpy(hv->init_buf, msg, VMBUS_MAX_PACKET_SIZE);
+		memcpy(hv->init_buf, msg, bytes_recvd);
 		complete(&hv->wait);
 		return;
 	}
 
 	if (msg->vid_hdr.type == SYNTHVID_FEATURE_CHANGE) {
+		if (bytes_recvd < hdr_size +
+		    sizeof(struct synthvid_feature_change))
+			return;
 		hv->dirt_needed = msg->feature_chg.is_dirt_needed;
 		if (hv->dirt_needed)
 			hyperv_hide_hw_ptr(hv->hdev);

@@ -466,7 +475,7 @@ static void hyperv_receive(void *ctx)
 				       &bytes_recvd, &req_id);
 		if (bytes_recvd > 0 &&
 		    recv_buf->pipe_hdr.type == PIPE_MSG_DATA)
-			hyperv_receive_sub(hdev);
+			hyperv_receive_sub(hdev, bytes_recvd);
 	} while (bytes_recvd > 0 && ret == 0);
 }
 

2.47.3

v2 folds two further issues into patch 1 that the sashiko-bot review pointed out on v1:

1. The resolution_count bounds check in v1 returned -ENODEV, but hyperv_connect_vsp() only logged a warning and continued without setting hv->screen_width_max / height_max / preferred_*. That left dev->mode_config.max_width and max_height at 0, which made drm_internal_framebuffer_create() reject every userspace framebuffer with -EINVAL. v2 falls back to the WIN8 defaults on that error path, matching the pre-WIN10 branch.

2. The three sequential VSP requests in hyperv_connect_vsp() (negotiate version, update VRAM location, get supported resolution) all wait on the same hv->wait completion without calling reinit_completion() between requests. A delayed complete() after a wait_for_completion_timeout() can leak into the next request and let it parse stale data out of hv->init_buf. v2 calls reinit_completion() before each send.

Patch 2 is unchanged from v1.

v1: https://lore.kernel.org/r/[email protected]

Berkant Koc (2):
drm/hyperv: validate resolution_count and harden VSP request paths drm/hyperv: validate VMBus packet size in receive callback

 drivers/gpu/drm/hyperv/hyperv_drm_proto.c | 32 ++++++++++++++++++-----
 1 file changed, 26 insertions(+), 6 deletions(-)

base-commit: 6916d5703ddf9a38f1f6c2cc793381a24ee914c6

2.47.3

The synthetic video device parses a SYNTHVID_RESOLUTION_RESPONSE that contains a u8 resolution_count and a u8 default_resolution_index. The existing check rejects resolution_count == 0 and an index greater or equal to resolution_count, but does not bound resolution_count itself against the fixed supported_resolution[SYNTHVID_MAX_RESOLUTION_COUNT] array. A host that returns resolution_count > 64 together with an in-range default_resolution_index causes the subsequent loop to read past the array. Reject any resolution_count that exceeds the array bound, folded into the existing zero-check so a single log entry remains per failure.

When that bounds check (or any later failure in hyperv_get_supported_resolution()) returns an error, the caller in hyperv_connect_vsp() previously logged a warning and continued without populating hv->screen_width_max / hv->screen_height_max / preferred_*. hyperv_mode_config_init() then set dev->mode_config.max_width and max_height to 0, which makes drm_internal_framebuffer_create() reject every userspace framebuffer with -EINVAL. Populate the fields with the WIN8 defaults that the pre-WIN10 branch already uses so a failed resolution probe degrades to a usable display instead of disabling it.

The driver also issues three sequential VSP requests (negotiate version, update VRAM location, get supported resolution) that share a single hv->wait completion. None of the call sites call reinit_completion() between requests. If wait_for_completion_timeout() returns 0 but a delayed response later triggers complete(&hv->wait) in the receive callback, the next request's wait can consume that stale completion, return immediately, and parse stale data out of hv->init_buf. Call reinit_completion() before each send so every request waits for its own response.

---
 drivers/gpu/drm/hyperv/hyperv_drm_proto.c | 17 ++++++++++++++---
 1 file changed, 14 insertions(+), 3 deletions(-)

index 051ecc526832..3b5065fe06e4 100644
@@ -223,6 +223,7 @@ static int hyperv_negotiate_version(struct hv_device *hdev, u32 ver)
 	msg->vid_hdr.size = sizeof(struct synthvid_msg_hdr) +
 		sizeof(struct synthvid_version_req);
 	msg->ver_req.version = ver;
+	reinit_completion(&hv->wait);
 	hyperv_sendpacket(hdev, msg);
 
 	t = wait_for_completion_timeout(&hv->wait, VMBUS_VSP_TIMEOUT);

@@ -257,6 +258,7 @@ int hyperv_update_vram_location(struct hv_device *hdev, phys_addr_t vram_pp)
 	msg->vram.user_ctx = vram_pp;
 	msg->vram.vram_gpa = vram_pp;
 	msg->vram.is_vram_gpa_specified = 1;
+	reinit_completion(&hv->wait);
 	hyperv_sendpacket(hdev, msg);
 
 	t = wait_for_completion_timeout(&hv->wait, VMBUS_VSP_TIMEOUT);

@@ -383,6 +385,7 @@ static int hyperv_get_supported_resolution(struct hv_device *hdev)
 		sizeof(struct synthvid_supported_resolution_req);
 	msg->resolution_req.maximum_resolution_count =
 		SYNTHVID_MAX_RESOLUTION_COUNT;
+	reinit_completion(&hv->wait);
 	hyperv_sendpacket(hdev, msg);
 
 	t = wait_for_completion_timeout(&hv->wait, VMBUS_VSP_TIMEOUT);

@@ -391,8 +394,11 @@ static int hyperv_get_supported_resolution(struct hv_device *hdev)
 		return -ETIMEDOUT;
 	}
 
-	if (msg->resolution_resp.resolution_count == 0) {
-		drm_err(dev, "No supported resolutions\n");
+	if (msg->resolution_resp.resolution_count == 0 ||
+	    msg->resolution_resp.resolution_count >
+	    SYNTHVID_MAX_RESOLUTION_COUNT) {
+		drm_err(dev, "Invalid resolution count: %d\n",
+			msg->resolution_resp.resolution_count);
 		return -ENODEV;
 	}
 

@@ -506,8 +512,13 @@ int hyperv_connect_vsp(struct hv_device *hdev)
 
 	if (hyperv_version_ge(hv->synthvid_version, SYNTHVID_VERSION_WIN10)) {
 		ret = hyperv_get_supported_resolution(hdev);
-		if (ret)
+		if (ret) {
 			drm_err(dev, "Failed to get supported resolution from host, use default\n");
+			hv->screen_width_max = SYNTHVID_WIDTH_WIN8;
+			hv->screen_height_max = SYNTHVID_HEIGHT_WIN8;
+			hv->preferred_width = SYNTHVID_WIDTH_WIN8;
+			hv->preferred_height = SYNTHVID_HEIGHT_WIN8;
+		}
 	} else {
 		hv->screen_width_max = SYNTHVID_WIDTH_WIN8;
 		hv->screen_height_max = SYNTHVID_HEIGHT_WIN8;

2.47.3

From: Berkant Koc <[email protected]> Sent: Sunday, May 17, 2026 7:25 AM

I think this is a good fix, but let me provide some background. A core assumption has been that the Hyper-V host is not malicious, and data from the host can be trusted to be well-formed and valid. Linux code interacting with the host does *not* take a paranoid approach and does *not* validate every value received from the host. Existing validation is ad hoc and probably not comprehensive.

A few years ago with the introduction of Confidential Computing and "CoCo VMs" in in Linux, the assumption changed. (Hyper-V calls these "Confidential VMs", or sometimes "Isolated VMs" -- unfortunately, the terminology is a bit scattered.) The host is treated as potentially malicious and Linux code was hardened against bad values passed from the host. But not all drivers for Hyper-V synthetic devices were hardened because CoCo VMs on Hyper-V don't allow all the possible synthetic devices. The Hyper-V synthetic frame buffer is one such disallowed device, so the Hyper-V DRM driver was not hardened. The allowed devices can be seen in the vmbus_devs[] array where .allowed_in_isolation is "true".

All that said, I'm in favor of adding hardening, even if it is done piecemeal. There won't likely be a comprehensive effort to harden the Hyper-V DRM driver unless the frame buffer device becomes available in a CoCo VM.

Yes, this also makes sense.

This change should probably be a separate patch, as it's not really related to the bounds checking issue. You could even argue that the bounds check and using the default size values in case of an error should be separate patches, but it's a judgment call and I could go either way. Combining the first two works for me, though someone else might disagree.

All that notwithstanding, I don't think your fix is needed in its current form. If wait_for_completion_timeout() times out in "negotiate version" or "update VRAM location", the code returns -ETIMEDOUT. The caller then bails out and does not send the next message in the sequence. Eventually hyperv_vmbus_probe() fails and the struct hyperv_drm_device memory is freed. A similar thing could happen with hyperv_vmbus_resume(). The memory isn't freed, but if the resume fails and is tried again later, it should be with a fresh copy of the saved memory image. In that case, the completion should be clean for the retry.

The problem case is "get supported resolution", which would leave the completion in a pending state if it times out. This could later affect hyperv_vmbus_resume(). I could see reinit'ing the completion in hyperv_vmbus_resume() to handle this case.

But double-check my thinking on all this. Maybe I'm missing something.

One other comment: In my view, your commit message is a bit too detailed. A commit message should focus on "why" the change, and less on the details of the implementation. Explaining the failure case is fine, but don't recapitulate code that is straightforward and obvious.

Hello Michael,

Thanks for the CoCo context, that lines up with what is in vmbus_devs[] for the framebuffer device. The piecemeal approach is what I am aiming for here.

v3 is on the list and addresses your three concrete points:

Dropped from v3. You are right that the negotiate-version and update-vram-location timeouts let hyperv_vmbus_probe() bail out and free the device, so the stale-completion path is only reachable from hyperv_vmbus_resume() after a get_supported_resolution() timeout. That is a narrower fix and belongs in a separate patch against the resume path, which I will send afterwards.

Yes, separate problem, and I missed it in v2. The pre-WIN10 branch in hyperv_connect_vsp() sets only screen_*_max and leaves preferred_* at zero, which is inconsistent with the WIN10-failure path.

Adopted in v3. The else branch is gone; the WIN10 path runs the probe and the post-probe block applies the WIN8 defaults whenever screen_width_max is still zero. One source of truth, both paths converge on it.

Rewritten in v3. The bounds check and the WIN8 fallback are now one short paragraph each, focused on the "why".

Series: <[email protected]>

The v3 patches carry an Assisted-by: Claude:claude-opus-4-7 berkoc-pipeline trailer per the kernel coding-assistants policy. Code, analysis and review responses are mine; the model is used as a structured reviewer under human verification.

Thanks,
Berkant

hyperv_receive() reads bytes_recvd from vmbus_recvpacket() but does not forward that value to hyperv_receive_sub(). The sub-handler reads msg->vid_hdr.type and msg->feature_chg.is_dirt_needed without knowing how many bytes the host actually wrote, so a short packet leaves the parser reading bytes that the host did not write in this packet. The unconditional memcpy(hv->init_buf, msg, VMBUS_MAX_PACKET_SIZE) on the wait-completion path also copies the full 16 KiB recv_buf regardless of bytes_recvd, including any residue from the prior message.

Pass bytes_recvd into hyperv_receive_sub() and reject any packet shorter than the pipe + synthvid header. The dirt-feature branch additionally requires the feature_change payload size before reading is_dirt_needed. The init_buf copy now uses bytes_recvd as the length argument, which keeps it bounded by VMBUS_MAX_PACKET_SIZE through the new upper check.

Unchanged from v1.

---
 drivers/gpu/drm/hyperv/hyperv_drm_proto.c | 15 ++++++++++++---
 1 file changed, 12 insertions(+), 3 deletions(-)

index 3b5065fe06e4..cdab4895dd40 100644
@@ -423,26 +423,35 @@ static int hyperv_get_supported_resolution(struct hv_device *hdev)
 	return 0;
 }
 
-static void hyperv_receive_sub(struct hv_device *hdev)
+static void hyperv_receive_sub(struct hv_device *hdev, u32 bytes_recvd)
 {
 	struct hyperv_drm_device *hv = hv_get_drvdata(hdev);
 	struct synthvid_msg *msg;
+	size_t hdr_size;
 
 	if (!hv)
 		return;
 
+	hdr_size = sizeof(struct pipe_msg_hdr) +
+		   sizeof(struct synthvid_msg_hdr);
+	if (bytes_recvd < hdr_size || bytes_recvd > VMBUS_MAX_PACKET_SIZE)
+		return;
+
 	msg = (struct synthvid_msg *)hv->recv_buf;
 
 	/* Complete the wait event */
 	if (msg->vid_hdr.type == SYNTHVID_VERSION_RESPONSE ||
 	    msg->vid_hdr.type == SYNTHVID_RESOLUTION_RESPONSE ||
 	    msg->vid_hdr.type == SYNTHVID_VRAM_LOCATION_ACK) {
-		memcpy(hv->init_buf, msg, VMBUS_MAX_PACKET_SIZE);
+		memcpy(hv->init_buf, msg, bytes_recvd);
 		complete(&hv->wait);
 		return;
 	}
 
 	if (msg->vid_hdr.type == SYNTHVID_FEATURE_CHANGE) {
+		if (bytes_recvd < hdr_size +
+		    sizeof(struct synthvid_feature_change))
+			return;
 		hv->dirt_needed = msg->feature_chg.is_dirt_needed;
 		if (hv->dirt_needed)
 			hyperv_hide_hw_ptr(hv->hdev);

@@ -469,7 +478,7 @@ static void hyperv_receive(void *ctx)
 				       &bytes_recvd, &req_id);
 		if (bytes_recvd > 0 &&
 		    recv_buf->pipe_hdr.type == PIPE_MSG_DATA)
-			hyperv_receive_sub(hdev);
+			hyperv_receive_sub(hdev, bytes_recvd);
 	} while (bytes_recvd > 0 && ret == 0);
 }
 

2.47.3

From: Berkant Koc <[email protected]> Sent: Sunday, May 17, 2026 7:25 AM

This is a valid concern. Similar patterns have hopefully been fixed in other drivers that were hardened for CoCo VMs.

Does copying the full 16 KiB break anything? Or are you flagging as just wasteful activity? This gets to what I previously mentioned about commit messages -- explain "why". Being wasteful is a valid reason, but it can be helpful to future readers to be explicit about the "why".

Version related comments should go below the "---" following the Signed-off line. They will be visible in the patch emails, but won't get put into the git log when the patch is finally accepted. The Linux kernel doesn't want to clutter the git log with intermediate version information that accumulates as the patch is reviewed and revised.

Hello Michael,

Thanks for the thorough review. v3 is on the list and addresses each point:

It is the residue read that is the actual hazard, not the copy cost:
the consumer that wakes on complete() then reads up to 16 KiB of bytes the host did not write in this packet as if it were the response payload. The v3 commit message now leads with that and treats "wasteful" as a secondary observation.

Moved into the cover letter changelog in v3 so it stays out of git log.

Dropped. The v3 check is bytes_recvd < hdr_size only.

Done in v3 via drm_err_ratelimited() on every short-packet path (synthvid header underflow, type-specific payload underflow, feature change underflow). The driver already uses drm_err_ratelimited() in hyperv_sendpacket() for the corresponding send path.

Fixed in v3. For the three completion types I now compute the required payload size with a switch on msg->vid_hdr.type and reject the packet before memcpy/complete:

SYNTHVID_VERSION_RESPONSE -> sizeof(struct synthvid_version_resp)
SYNTHVID_RESOLUTION_RESPONSE -> sizeof(struct synthvid_supported_resolution_resp)
SYNTHVID_VRAM_LOCATION_ACK -> sizeof(struct synthvid_vram_location_ack)

The memcpy then uses bytes_recvd, so wait_for_completion_timeout() consumers never see truncated data and never read past what the host wrote.

Series: <[email protected]>

The v3 patches carry an Assisted-by: Claude:claude-opus-4-7 berkoc-pipeline trailer per the kernel coding-assistants policy. Code, analysis and review responses are mine; the model is used as a structured reviewer under human verification.

Thanks,
Berkant

Two independent issues in the synthetic video driver that both stem from trusting unvalidated host data.

1/2 bounds resolution_count from SYNTHVID_RESOLUTION_RESPONSE against the supported_resolution[] array, and populates WIN8 defaults for hv->screen_*_max / hv->preferred_* in both the WIN10-probe-failure path and the pre-WIN10 path, so a failed or pre-WIN10 probe yields a usable display instead of having drm_internal_framebuffer_create() reject every userspace framebuffer with -EINVAL.

2/2 forwards bytes_recvd from vmbus_recvpacket() into the sub-handler, rejects packets that do not cover the synthvid header, and additionally requires the type-specific payload size before memcpy/complete or before reading the feature-change byte. Rejected packets are logged via drm_err_ratelimited() instead of being silently dropped, matching the CoCo-hardened pattern in hv_kvp_onchannelcallback().

Changes since v2 (per review by Michael Kelley):

1/2: dropped the reinit_completion() change. Kelley pointed out that
the negotiate-version and update-vram-location timeouts cause hyperv_vmbus_probe() to fail and free the device, so the stale completion can only outlive its request in hyperv_vmbus_resume() after a get_supported_resolution() timeout. That is a narrower fix and belongs in a separate patch against the resume path. Subject and commit message rewritten to reflect that this patch is now bounds-check + WIN8 fallback only. Pre-WIN10 branch now also populates hv->preferred_* (Kelley spotted the gap). Followed the post-probe-test refactor Kelley suggested: the else branch is gone, a single screen_width_max == 0 check covers both the pre-WIN10 case and a failed WIN10 probe.

2/2: dropped the redundant upper bound on bytes_recvd. Added a
per-type switch for the three completion-driving message types (SYNTHVID_VERSION_RESPONSE, SYNTHVID_RESOLUTION_RESPONSE, SYNTHVID_VRAM_LOCATION_ACK) so the wait-completion path validates payload size before memcpy/complete. Every reject path now emits drm_err_ratelimited() rather than returning silently. Commit message rewritten to lead with the residue read, with "wasteful copy" reframed as the secondary observation.

Changes since v1:
1/2: bound resolution_count check folded into the existing zero
check; populate WIN8 defaults when hyperv_get_supported_resolution() fails.
2/2: forward bytes_recvd into hyperv_receive_sub(); enforce the
pipe + synthvid header minimum; check synthvid_feature_change payload size before reading is_dirt_needed.

Both patches carry an Assisted-by: Claude:claude-opus-4-7 berkoc-pipeline trailer per the kernel coding-assistants policy. Code, analysis and review responses are mine; the model is used as a structured reviewer under human verification.

base-commit: 4bf5d3da79c48e1df4bab82c9680c53adeff7820

Berkant Koc (2):
drm/hyperv: validate resolution_count and fix WIN8 fallback drm/hyperv: validate VMBus packet size in receive callback

 drivers/gpu/drm/hyperv/hyperv_drm_proto.c | 58 ++++++++++++++++++++---
 1 file changed, 52 insertions(+), 6 deletions(-)

--
2.47.3

A SYNTHVID_RESOLUTION_RESPONSE with resolution_count > 64 walks past the supported_resolution[SYNTHVID_MAX_RESOLUTION_COUNT] array in the parse loop. Bound resolution_count against the array size, folded into the existing zero-check.

When the WIN10 resolution probe fails, the caller in hyperv_connect_vsp() left hv->screen_*_max / preferred_* unpopulated, which sets mode_config.max_width / max_height to 0 and makes drm_internal_framebuffer_create() reject every userspace framebuffer with -EINVAL. The pre-WIN10 branch had the same gap for preferred_width / preferred_height. Use a single post-probe fallback guarded by screen_width_max == 0 so both paths converge on the WIN8 defaults.

---
 drivers/gpu/drm/hyperv/hyperv_drm_proto.c | 13 ++++++++++---
 1 file changed, 10 insertions(+), 3 deletions(-)

index 051ecc526..c3d0ff229 100644
@@ -391,8 +391,11 @@ static int hyperv_get_supported_resolution(struct hv_device *hdev)
 		return -ETIMEDOUT;
 	}
 
-	if (msg->resolution_resp.resolution_count == 0) {
-		drm_err(dev, "No supported resolutions\n");
+	if (msg->resolution_resp.resolution_count == 0 ||
+	    msg->resolution_resp.resolution_count >
+	    SYNTHVID_MAX_RESOLUTION_COUNT) {
+		drm_err(dev, "Invalid resolution count: %d\n",
+			msg->resolution_resp.resolution_count);
 		return -ENODEV;
 	}
 

@@ -508,9 +511,13 @@ int hyperv_connect_vsp(struct hv_device *hdev)
 		ret = hyperv_get_supported_resolution(hdev);
 		if (ret)
 			drm_err(dev, "Failed to get supported resolution from host, use default\n");
-	} else {
+	}
+
+	if (!hv->screen_width_max) {
 		hv->screen_width_max = SYNTHVID_WIDTH_WIN8;
 		hv->screen_height_max = SYNTHVID_HEIGHT_WIN8;
+		hv->preferred_width = SYNTHVID_WIDTH_WIN8;
+		hv->preferred_height = SYNTHVID_HEIGHT_WIN8;
 	}
 
 	hv->mmio_megabytes = hdev->channel->offermsg.offer.mmio_megabytes;

2.47.3

From: Berkant Koc <[email protected]> Sent: Tuesday, May 19, 2026 1:08 PM

Looks good to me.

hyperv_receive_sub() reads msg->vid_hdr.type and dispatches into one of four message-type branches without knowing how many bytes the host wrote into hv->recv_buf. The completion path then runs memcpy(hv->init_buf, msg, VMBUS_MAX_PACKET_SIZE), so the consumer that wakes on wait_for_completion_timeout() can read up to 16 KiB of residue from a prior message as if it were the response payload.

Pass bytes_recvd into hyperv_receive_sub() and reject any packet that does not cover the pipe + synthvid header. For each of the three completion-driving types (SYNTHVID_VERSION_RESPONSE, SYNTHVID_RESOLUTION_RESPONSE, SYNTHVID_VRAM_LOCATION_ACK) also require the type-specific payload before memcpy/complete, and apply the same rule to SYNTHVID_FEATURE_CHANGE before reading is_dirt_needed. The memcpy then uses bytes_recvd, which is bounded by VMBUS_MAX_PACKET_SIZE through the call to vmbus_recvpacket().

Rejected packets are reported via drm_err_ratelimited() rather than silently dropped, matching the CoCo-hardened pattern in hv_kvp_onchannelcallback().

---
 drivers/gpu/drm/hyperv/hyperv_drm_proto.c | 42 +++++++++++++++++++++--
 1 file changed, 39 insertions(+), 3 deletions(-)

index c3d0ff229..12d3feb4f 100644
@@ -420,26 +420,62 @@ static int hyperv_get_supported_resolution(struct hv_device *hdev)
 	return 0;
 }
 
-static void hyperv_receive_sub(struct hv_device *hdev)
+static void hyperv_receive_sub(struct hv_device *hdev, u32 bytes_recvd)
 {
 	struct hyperv_drm_device *hv = hv_get_drvdata(hdev);
 	struct synthvid_msg *msg;
+	size_t hdr_size;
 
 	if (!hv)
 		return;
 
+	hdr_size = sizeof(struct pipe_msg_hdr) +
+		   sizeof(struct synthvid_msg_hdr);
+	if (bytes_recvd < hdr_size) {
+		drm_err_ratelimited(&hv->dev,
+				    "synthvid packet too small for header: %u\n",
+				    bytes_recvd);
+		return;
+	}
+
 	msg = (struct synthvid_msg *)hv->recv_buf;
 
 	/* Complete the wait event */
 	if (msg->vid_hdr.type == SYNTHVID_VERSION_RESPONSE ||
 	    msg->vid_hdr.type == SYNTHVID_RESOLUTION_RESPONSE ||
 	    msg->vid_hdr.type == SYNTHVID_VRAM_LOCATION_ACK) {
-		memcpy(hv->init_buf, msg, VMBUS_MAX_PACKET_SIZE);
+		size_t need = hdr_size;
+
+		switch (msg->vid_hdr.type) {
+		case SYNTHVID_VERSION_RESPONSE:
+			need += sizeof(struct synthvid_version_resp);
+			break;
+		case SYNTHVID_RESOLUTION_RESPONSE:
+			need += sizeof(struct synthvid_supported_resolution_resp);
+			break;
+		case SYNTHVID_VRAM_LOCATION_ACK:
+			need += sizeof(struct synthvid_vram_location_ack);
+			break;
+		}
+		if (bytes_recvd < need) {
+			drm_err_ratelimited(&hv->dev,
+					    "synthvid packet too small for type %u: %u < %zu\n",
+					    msg->vid_hdr.type, bytes_recvd, need);
+			return;
+		}
+		memcpy(hv->init_buf, msg, bytes_recvd);
 		complete(&hv->wait);
 		return;
 	}
 
 	if (msg->vid_hdr.type == SYNTHVID_FEATURE_CHANGE) {
+		if (bytes_recvd < hdr_size +
+		    sizeof(struct synthvid_feature_change)) {
+			drm_err_ratelimited(&hv->dev,
+					    "synthvid feature change packet too small: %u\n",
+					    bytes_recvd);
+			return;
+		}
 		hv->dirt_needed = msg->feature_chg.is_dirt_needed;
 		if (hv->dirt_needed)
 			hyperv_hide_hw_ptr(hv->hdev);

@@ -466,7 +502,7 @@ static void hyperv_receive(void *ctx)
 				       &bytes_recvd, &req_id);
 		if (bytes_recvd > 0 &&
 		    recv_buf->pipe_hdr.type == PIPE_MSG_DATA)
-			hyperv_receive_sub(hdev);
+			hyperv_receive_sub(hdev, bytes_recvd);
 	} while (bytes_recvd > 0 && ret == 0);
 }
 

2.47.3

This one is bounded on this channel. hyperv_connect_vsp() calls vmbus_open() without setting max_pkt_size, so the inbound ring uses VMBUS_DEFAULT_MAX_PKT_SIZE (4096) and hv_pkt_iter_first() clamps the packet length to pkt_buffer_size. bytes_recvd therefore cannot exceed 4096, well under the 16 KiB recv_buf and init_buf, and vmbus_recvpacket() does not return -ENOBUFS here, so the memcpy length stays bounded.

I will still gate the dispatch on a successful vmbus_recvpacket() return in the next revision, as defense in depth, so the bound is local instead of relying on the ring clamp.

Agreed. The response carries resolution_count entries, not the full SYNTHVID_MAX_RESOLUTION_COUNT array, so checking against sizeof(struct synthvid_supported_resolution_resp) is too strict. The next revision validates the fixed prefix, reads and bounds resolution_count, then requires only the count-sized array.

Both pre-existing. On v2 Michael Kelley suggested splitting the completion reinit into a separate patch on the resume path. The init_buf reuse sits in the same area, so I plan to send the reinit and the related response-type handling as a separate follow-up rather than fold them into this size-validation change.

Thanks for the review.

Berkant

From: Berkant Koc <[email protected]> Sent: Wednesday, May 20, 2026 6:24 AM

Actually, the behavior of vmbus_recvpacket() is more subtle, and the problem pointed out by Sashiko AI is real. I had forgotten about this subtle behavior in my first reply to you on this topic. :-(

The incoming message from Hyper-V has a length encoded in it. hv_ringbuffer_read() gets that message length, and if it is larger than the buflen_parameter, -ENOBUFS is returned. But the returned buffer_actual_len is also set to the incoming message length provided by Hyper-V. This allows the caller to realize it didn't provide enough buffer space, and also tells it how much buffer space is needed. hv_pci_onchannelcallback() uses this functionality to retry the receive operation with a larger buffer. I think all the other callers just treat -ENOBUFS as a fatal error, which is also fine.

Indeed, the error check is needed, and it's not just defense in depth.

OK, good.

I don't think this actually happens. In hv_pkt_iter_first(), the message is copied out of the ring buffer into a temporary buffer that is not explicitly shared with the host. This temporary copy prevents a malicious host from modifying the data while the guest is validating it.

Handling a timeout, and then the host providing a belated response is a really messy problem. There's some mechanism using request IDs in hv_ringbuffer_write() and vmbus_sendpacket_getid() to help match up requests and responses, but my recollection is that even this extra machinery is not 100% foolproof. You may or may not want to go down the path of trying to fix it. :-)

A process comment: The emails for v2 and v3 of your patch set are being threaded in an unexpected way. They are showing up
as replies under the original v1. See https://lore.kernel.org/linux-hyperv/.
The preferred approach is for each version to start a new email thread. The cover letter should start the new thread, and the patches should show up as threaded under the cover letter.

Also, don't post a new version more frequently than every 24 hours at a minimum, and there's no problem with waiting 2 to 3 days. The idea is to give people a chance to review and provide comments so that you can batch any changes in response to the feedback.

Michael

From: Berkant Koc <[email protected]> Sent: Tuesday, May 19, 2026 1:09 PM

We discussed several issues with this patch in the feedback from Sashiko. But see one more issue below.