From: Berkant Koc <me@berkoc.com>
To: Saurabh Sengar <ssengar@linux.microsoft.com>,
Dexuan Cui <decui@microsoft.com>, Long Li <longli@microsoft.com>
Cc: linux-hyperv@vger.kernel.org, dri-devel@lists.freedesktop.org,
linux-kernel@vger.kernel.org,
K. Y. Srinivasan <kys@microsoft.com>,
Haiyang Zhang <haiyangz@microsoft.com>,
Wei Liu <wei.liu@kernel.org>,
Michael Kelley <mhklinux@outlook.com>,
Thomas Zimmermann <tzimmermann@suse.de>,
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Maxime Ripard <mripard@kernel.org>,
Deepak Rawat <drawat.floss@gmail.com>
Subject: [PATCH v3 0/2] drm/hyperv: harden host message parsing
Date: Tue, 19 May 2026 22:08:59 +0200 [thread overview]
Message-ID: <cover.1779221339.git.me@berkoc.com> (raw)
In-Reply-To: <20260517-drm-hyperv-cover-v2@berkoc.com>
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
next prev parent reply other threads:[~2026-05-19 20:23 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-17 12:55 [PATCH 0/2] drm/hyperv: harden VMBus message parser input validation Berkant Koc
2026-05-17 12:55 ` [PATCH 1/2] drm/hyperv: validate resolution_count from host VMBus message Berkant Koc
2026-05-17 13:49 ` sashiko-bot
2026-05-17 12:55 ` [PATCH 2/2] drm/hyperv: validate VMBus packet size in receive callback Berkant Koc
2026-05-17 14:17 ` sashiko-bot
2026-05-17 14:25 ` [PATCH v2 0/2] drm/hyperv: harden VMBus message parser input validation Berkant Koc
2026-05-17 14:25 ` [PATCH v2 1/2] drm/hyperv: validate resolution_count and harden VSP request paths Berkant Koc
2026-05-17 14:47 ` sashiko-bot
2026-05-19 18:33 ` Michael Kelley
2026-05-19 20:20 ` Berkant Koc
2026-05-17 14:25 ` [PATCH v2 2/2] drm/hyperv: validate VMBus packet size in receive callback Berkant Koc
2026-05-17 15:13 ` sashiko-bot
2026-05-19 18:33 ` Michael Kelley
2026-05-19 20:20 ` Berkant Koc
2026-05-19 20:08 ` Berkant Koc [this message]
2026-05-19 20:08 ` [PATCH v3 1/2] drm/hyperv: validate resolution_count and fix WIN8 fallback Berkant Koc
2026-05-19 20:55 ` sashiko-bot
2026-05-21 17:07 ` Michael Kelley
2026-05-19 20:08 ` [PATCH v3 2/2] drm/hyperv: validate VMBus packet size in receive callback Berkant Koc
2026-05-19 21:34 ` sashiko-bot
2026-05-20 13:23 ` Berkant Koc
2026-05-20 14:24 ` Michael Kelley
2026-05-21 17:19 ` Michael Kelley
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=cover.1779221339.git.me@berkoc.com \
--to=me@berkoc.com \
--cc=decui@microsoft.com \
--cc=drawat.floss@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=haiyangz@microsoft.com \
--cc=kys@microsoft.com \
--cc=linux-hyperv@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=longli@microsoft.com \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mhklinux@outlook.com \
--cc=mripard@kernel.org \
--cc=ssengar@linux.microsoft.com \
--cc=tzimmermann@suse.de \
--cc=wei.liu@kernel.org \
/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.