All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.