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 v4 0/2] drm/hyperv: harden host message parsing
Date: Thu, 21 May 2026 22:41:14 +0200 [thread overview]
Message-ID: <cover.1779396074.git.me@berkoc.com> (raw)
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 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().
1/2 is unchanged from v3 and carries Michael Kelley's Reviewed-by.
Changes since v3 (per review by Michael Kelley):
2/2: validate SYNTHVID_RESOLUTION_RESPONSE against its actual
variable length. The response carries resolution_count entries,
not the full SYNTHVID_MAX_RESOLUTION_COUNT array, so requiring
sizeof(struct synthvid_supported_resolution_resp) rejected the
shorter responses the host legitimately sends and broke
resolution probing. Require the fixed prefix, read and bound
resolution_count, then require only the count-sized array.
2/2: only run hyperv_receive_sub() when vmbus_recvpacket() returned
success. v3 dropped the bytes_recvd upper bound as redundant,
which holds only on a successful receive: on -ENOBUFS
vmbus_recvpacket() reports the required length in bytes_recvd,
which can exceed the 16 KiB hv->recv_buf, and the subsequent
memcpy(hv->init_buf, msg, bytes_recvd) would read and write
past both buffers. Gating on the success return restores the
invariant that made the bound redundant, so an oversized host
packet is dropped rather than copied.
Changes since v2 (per review by Michael Kelley):
1/2: dropped the reinit_completion() change; the stale completion can
only outlive its request in hyperv_vmbus_resume() after a
get_supported_resolution() timeout, which is a narrower fix that
belongs in a separate patch against the resume path. Pre-WIN10
branch now also populates hv->preferred_*. 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: added a per-type switch for the three completion-driving message
types so the wait-completion path validates payload size before
memcpy/complete. Every reject path emits drm_err_ratelimited()
rather than returning silently.
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.
The shared init_buf reuse (a duplicate or late host response can
overwrite init_buf between successive request/response cycles) and the
related completion reinit are real but orthogonal to this size
validation. As discussed on v2, they are queued as a separate follow-up
against the resume/expected-type path once this series lands.
This series is verified by static analysis and code inspection against
the synthvid protocol structures and the vmbus_recvpacket() contract. I
do not currently have a Hyper-V test environment to exercise the receive
and resolution-probe paths at runtime, so confirmation from someone who
can run it in a Hyper-V VM would be welcome.
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.
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 | 76 ++++++++++++++++++++---
1 file changed, 69 insertions(+), 7 deletions(-)
base-commit: 4bf5d3da79c48e1df4bab82c9680c53adeff7820
--
2.47.3
next reply other threads:[~2026-05-21 20:55 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-21 20:41 Berkant Koc [this message]
2026-05-19 20:08 ` [PATCH v4 1/2] drm/hyperv: validate resolution_count and fix WIN8 fallback Berkant Koc
2026-05-21 21:26 ` sashiko-bot
2026-05-19 20:08 ` [PATCH v4 2/2] drm/hyperv: validate VMBus packet size in receive callback Berkant Koc
2026-05-21 22:06 ` sashiko-bot
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.1779396074.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox