From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-03.1984.is (mail-03.1984.is [93.95.224.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9714025B0AA; Sat, 23 May 2026 13:59:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=93.95.224.70 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779544749; cv=none; b=GDOaU1xzPjC2urHJTbh+HLK1wsGHnS69+zgYSLDocZUxrnsKce+ijpftLgZptyyCwCxzqvKMrbM0tSd8YCpUMklhqvC6EiM6znioy0P0+A/oqFbKKUtp/OeTCqAO84FWEws/8ix790guSo1w62LU+eZ+L6f7eTuyY8a/qWiwTxc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779544749; c=relaxed/simple; bh=FFDXoVXQmLtVPEZdyCChcI4fmDsy41lJVmTuSnI2jwE=; h=Message-ID:From:To:Cc:Date:Subject; b=p5aeR+x1Wwp/rYve3w/F9h8QKmR4kXN0f8wZ+IRvvX/IGNbPVdBmP8wwltoAdBVAojflxR5Fw6KLods/dnExveP+ESzzz6b6EtyPOZ5YzV/xDWJc2LIQ+8/rhttesL4vN7YC+O6TKyBLqLd2hiQQYNnzK1yFKEW9CXk4lT5xne4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=berkoc.com; spf=pass smtp.mailfrom=berkoc.com; dkim=pass (2048-bit key) header.d=berkoc.com header.i=@berkoc.com header.b=hVoif81v; dkim=pass (2048-bit key) header.d=berkoc.com header.i=@berkoc.com header.b=YKDlhUk1; arc=none smtp.client-ip=93.95.224.70 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=berkoc.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=berkoc.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=berkoc.com header.i=@berkoc.com header.b="hVoif81v"; dkim=pass (2048-bit key) header.d=berkoc.com header.i=@berkoc.com header.b="YKDlhUk1" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=berkoc.com; s=1984; h=Subject:Date:Cc:To:From:Message-ID:Sender:Reply-To:MIME-Version: Content-Type:Content-Transfer-Encoding:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=AfbvvKdcTGdnNuSgMETMip6O9mEDFZRdMO+Wt+D6oX8=; b=hVoif81vuqwzeV6+lOaABVLsEA KYwGxxTlt9nTPqzXrsi/mXq8AkmGiW21IVN5fOgjbRTlBeqtWt4HVZiQHx1faokgpSpXPHr4UG4BA prEvjfWLV4ZiNih6FUhkESwxubQIiFR8BsNGEoH7281Rs4/1f2XmhrXlrWvsBFQI1Nb2dPXw5ySZq 7XM0+9Zg9SoCRfBI7tohUQM5xDzx92cZR6l/x+qR2uU8wX6ET23/d5f/nUa+tiXjXS1KZObwOsNmB nWkWx2ku5cjG+xN2qzyZBajz2qO+uWrtKk9qkmC1fxRMPXxDlDi2KEIjWJAHMNidqMQS7b+Nc021i Jezk7TbA==; Received: from localhost by mail-03.1984.is with utf8esmtp (Exim 4.96) (envelope-from ) id 1wQmsV-004m47-10; Sat, 23 May 2026 13:59:04 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=berkoc.com; i=@berkoc.com; q=dns/txt; s=me; t=1779544724; h=message-id : date : subject : cc : to : from : sender : reply-to; bh=AfbvvKdcTGdnNuSgMETMip6O9mEDFZRdMO+Wt+D6oX8=; b=YKDlhUk1WRDcfLlqbEx1pmDQT1Un40SIonJfzUhPiA7unMfdXQehZ6GfgKYrEw0FKPZfe 9ENtTS3y/2TWaBvo9IQ5UI/dHrLrL5pIYLLfbkEiRsCcIYJKoZoYrMe2hMxqL4Q39A2k66b BKypGZULauBnmVNGpAJAEAtr8YCSEOkBe/piOnb6mhx2wwMA/Cd/JnUWpVttTY2taO8sYpQ wzZ5ZoY4LqC+QfH2bnk6GMAEixKkmjFNXOkKOUo00Qm4c4aHsknknsdJ3Aishp/vt9F8R3G cnouZEgmlzwoaGLVaXM4NumrjCgcVWuyDquutkHZt2ODDDBmLDXy80sI5mHw== Message-ID: From: Berkant Koc To: Saurabh Sengar , Dexuan Cui , Long Li Cc: linux-hyperv@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, K. Y. Srinivasan , Haiyang Zhang , Wei Liu , Michael Kelley , Thomas Zimmermann , Maarten Lankhorst , Maxime Ripard , Deepak Rawat Date: Sat, 23 May 2026 15:27:54 +0200 Subject: [PATCH v5 0/2] drm/hyperv: harden host message parsing X-Spam-Score: -0.2 (/) X-Authenticated-User: me@berkoc.com X-Sender-Address: me@berkoc.com Precedence: bulk X-Mailing-List: linux-hyperv@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: 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/v4 and carries Michael Kelley's Reviewed-by. Changes since v4 (per review by Michael Kelley): 2/2: collapsed the leading "if (type == ... ) { ... switch ... }" plus the separate "if (type == FEATURE_CHANGE)" into a single switch on msg->vid_hdr.type. The three completion-driving cases compute their per-type size and break to a shared exit that does the size check + memcpy(init_buf) + complete(); FEATURE_CHANGE is its own case that validates its payload and returns without falling through; unknown types hit default and return. No functional change, fewer lines. 2/2: the vmbus_recvpacket() nonzero-return path (e.g. -ENOBUFS for a too-big packet) is itself a malformed-message case. It is now logged via drm_err_ratelimited(), consistent with the sub-handler's other reject paths, instead of being silently skipped. No channel recovery is attempted, as that is not worth the added code for this rare host-side condition. 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 | 113 +++++++++++++++++++--- 1 file changed, 97 insertions(+), 16 deletions(-) base-commit: 4bf5d3da79c48e1df4bab82c9680c53adeff7820 -- 2.47.3