From nobody Sun May 24 20:33:09 2026 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 E831333E35B; Sat, 23 May 2026 13:59:28 +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=1779544771; cv=none; b=VWe6vGhp0vhoI1ChifPQTbRzVOO9AYdKi8ALOnMmKJ9cu4mMd9W+lt/YkPStCf8geRc4VS9pqpqXoH2UgFj06qOtHv8ZdhRQeO/ExgitAtMASBYWOS6Sk65D8aktEADWTGjGjD49H1y6M5J+S+5txOGjkekgQSxsyv9SMBD3Vqs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779544771; c=relaxed/simple; bh=ILuFrIOgTO8y5W1rv5THOEIkmcdLmOdqUeFLjCyS2Xs=; h=Message-ID:In-Reply-To:References:From:To:Cc:Date:Subject; b=Plt2bGGL8QD/vIytPmE++9w69uvlmFi7Up2TlzQloev/wtai/73c6SrQmCawrVDZPhhlcjyq8qSJEe8iRbSt5elys9hoHJb8LXBkLJx3Bq4Qg3Mnm9lT9M4T38ZQv0EndddK7ep+M6M5NvbNWxWNn8eSkl1WKdcHtx/V6Jt5WNo= 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=Snk5RZ0l; dkim=pass (2048-bit key) header.d=berkoc.com header.i=@berkoc.com header.b=FWqZW+86; 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="Snk5RZ0l"; dkim=pass (2048-bit key) header.d=berkoc.com header.i=@berkoc.com header.b="FWqZW+86" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=berkoc.com; s=1984; h=Subject:Date:Cc:To:From:References:In-Reply-To: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:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=yEgrKS1yuvRt1SapJoA7ktrpyTmlvnKNqxmZJDoUF6o=; b=Snk5RZ0lbfY2zD4XrnFehj7llD TsBfM9yHtksiAoNpZ+d4KMVhRyFUXvS2ULL7kQRxVzSz16wFJHpg2PfwoI9+nw3M2904Bjtd1Znu7 cVg8lrJGneP13Me3T/OYCdkwy9n+Bmj/U9A1woM+WJ34xLQ7FjLE+9437L0vE+efPqTnNQbhvYpz5 ix9SBx1JAFYAdFUdXo685b/REoz6fyv6Yb3ex27pvn4ZYniI/WzP8sD7PDn0aF8DVO8TvqJlRRfrR U4WPl9TdxIgcU++ZBmO6EilKy/Db1Uh64gVcKaAeCJU7aBseJecxuZdQ47hpFHFJEKONVvDSK45L2 OKfz0oKw==; Received: from localhost by mail-03.1984.is with utf8esmtp (Exim 4.96) (envelope-from ) id 1wQmsu-004mB3-1K; Sat, 23 May 2026 13:59:25 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=berkoc.com; i=@berkoc.com; q=dns/txt; s=me; t=1779544752; h=message-id : date : subject : cc : to : from : sender : reply-to; bh=yEgrKS1yuvRt1SapJoA7ktrpyTmlvnKNqxmZJDoUF6o=; b=FWqZW+86/YJ+Hdt8DHHQ2s3zs0tbmTsspFIx94URgEeY8Zf6NqcXikXU22A+f4bUNgd94 o++WP2q9kJ1k5Hyy6GAHDHJVBsog6N65KvGZdLgS7Y4eY0ZcyjOsbTvkZU8s6wnlvolP/KI r2bWLOZbVbM25+7Vs10P4qbpo9xtE491WDeFZKjLI/3nzEasPSiCBRRJr5d5nEpiFDyuRdP G1ZV3KGJDKUra4yGpousXkukgDWg8JhpIP16STMSaqZ6jZZGwfatgdIfcF0ZEy9do1FJ7sZ XemwDhBYDRWus5S7B1Yg6j3TRb7VkgbLD/XcUw5KGF9vbRBdkD7vb8tr+aqg== Message-ID: <6945b22419c7d404b4954a113de2ac9c900dba93.1779542874.git.me@berkoc.com> In-Reply-To: References: 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: Tue, 19 May 2026 22:08:17 +0200 Subject: [PATCH v5 1/2] drm/hyperv: validate resolution_count and fix WIN8 fallback X-Spam-Score: -0.2 (/) X-Authenticated-User: me@berkoc.com X-Sender-Address: me@berkoc.com Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" 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 =3D=3D 0 so both paths converge on the WIN8 defaults. Signed-off-by: Berkant Koc Assisted-by: Claude:claude-opus-4-7 berkoc-pipeline Fixes: 76c56a5affeb ("drm/hyperv: Add DRM driver for hyperv synthetic video= device") Cc: stable@vger.kernel.org # 5.14+ Reviewed-by: Michael Kelley --- drivers/gpu/drm/hyperv/hyperv_drm_proto.c | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/hyperv/hyperv_drm_proto.c b/drivers/gpu/drm/hy= perv/hyperv_drm_proto.c index 051ecc526..c3d0ff229 100644 --- a/drivers/gpu/drm/hyperv/hyperv_drm_proto.c +++ b/drivers/gpu/drm/hyperv/hyperv_drm_proto.c @@ -391,8 +391,11 @@ static int hyperv_get_supported_resolution(struct hv_d= evice *hdev) return -ETIMEDOUT; } =20 - if (msg->resolution_resp.resolution_count =3D=3D 0) { - drm_err(dev, "No supported resolutions\n"); + if (msg->resolution_resp.resolution_count =3D=3D 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; } =20 @@ -508,9 +511,13 @@ int hyperv_connect_vsp(struct hv_device *hdev) ret =3D 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 =3D SYNTHVID_WIDTH_WIN8; hv->screen_height_max =3D SYNTHVID_HEIGHT_WIN8; + hv->preferred_width =3D SYNTHVID_WIDTH_WIN8; + hv->preferred_height =3D SYNTHVID_HEIGHT_WIN8; } =20 hv->mmio_megabytes =3D hdev->channel->offermsg.offer.mmio_megabytes; --=20 2.47.3 From nobody Sun May 24 20:33:09 2026 Received: from mail-01.1984.is (mail-01.1984.is [185.112.145.69]) (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 BE5A538398A; Sat, 23 May 2026 13:59:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.112.145.69 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779544797; cv=none; b=rHq5LiJVUOF1Uq7eHmqBN951GNcWnkY9ujFVrnSOfn4lUI7MyYEDW123soUqGWfFzUtvOc5UiifmTNLYwX5mu8mI5HG4cR7QWsitIT5KmYSFY+q6mEGygALjL2eUW5wdmLGcrhxQFsr+ghHo4zfwh/h62rzsTLVTog0/xnFaCtw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779544797; c=relaxed/simple; bh=13icOsQUx42+l1Kd3fjRTfYktzRT2SpNRElys5n1fVk=; h=Message-ID:In-Reply-To:References:From:To:Cc:Date:Subject; b=tIcaId+jw5wU6Lb9CYfYDGuj8IPerkFgO2N2McoIMaqlzqfWKpFsHj289nsTgoYprE/MbFRHzLq7APrsGokQBRKAdV1hsiTblkriam/HFJVS/dqPXao2Lv8PwKBlhsCpBS6OTP55UIiFfwKqx5EVWQnmJHDjDjLnMWFKYIo/t98= 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=mrk1vc7T; dkim=pass (2048-bit key) header.d=berkoc.com header.i=@berkoc.com header.b=lWfbSflJ; arc=none smtp.client-ip=185.112.145.69 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="mrk1vc7T"; dkim=pass (2048-bit key) header.d=berkoc.com header.i=@berkoc.com header.b="lWfbSflJ" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=berkoc.com; s=1984; h=Subject:Date:Cc:To:From:References:In-Reply-To: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:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=26k+rdY2gpZelGKCvHSPGK8DaUvnKiOQCsWI4Tqj72w=; b=mrk1vc7TQSz0skuNC4ao37E+pv UFYfnvxQXn+A3oSBqYMRUwJQgqaKcNa4N9aDKuARWY68hf4T48Mr7WAmxNJhE8MJP6VP30/3Gz0fO iq9cSDv+4WmVzMt77+IfVuFfmleQJlUNTt2BbqXzxHf0KlD3iIdGC6KDGE6FEn06TLysKYR1xDKD9 KWTIbcAJNF04XKCvxHJT+WyoPuGs3g7a5gr+JgoHW1PMD5yEIfqG11Y/Pq0q5CiEJmPKycT2FYMiO WRZ1MAa1MWQT9b+wDn6Mzu5/FNotz+Dqa63Zvd7uVPmee9IVO1YChe6wSrC9elv4B9XakSxcfzysY bV9ep0Nw==; Received: from localhost by mail-01.1984.is with utf8esmtp (Exim 4.96) (envelope-from ) id 1wQmtE-0024QH-2n; Sat, 23 May 2026 13:59:45 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=berkoc.com; i=@berkoc.com; q=dns/txt; s=me; t=1779544773; h=message-id : date : subject : cc : to : from : sender : reply-to; bh=26k+rdY2gpZelGKCvHSPGK8DaUvnKiOQCsWI4Tqj72w=; b=lWfbSflJeCRuniQplYUDi4K/8RVxQSRZW2DTtvvAA373LCuRTms0yKi15Z//+QHWSYARV NsK4NS3P9PhCuhtDHKBPUEWlEqaDCQBpnqiI39wIP2OUrPqL2TwkEnmBPIJf7WUTUgWFWsR Qr4PMiz5iMXvXdID2IOcGjGB5vB9rBkflTMgZeI0wYebjLc40NS7PVYFu6D9ft5iWUw906o nAQ/2rUvC7Fc9Bt0YKcjhbU5W+D4mK0zfhMq4HsU3FwU1W/+N6hM9wAe+Z57v5IhBxv0mnT 3cvS9Ojjfw/LjYE5W4Q3/DgVZ7xW/WexpUTiMSbUzdOsJ0aDHx9jVIdK3N8g== Message-ID: <8200dbc199c7a9b75ac7e8af6c748d2189b5ebd5.1779542874.git.me@berkoc.com> In-Reply-To: References: 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:47 +0200 Subject: [PATCH v5 2/2] drm/hyperv: validate VMBus packet size in receive callback X-Spam-Score: -0.2 (/) X-Authenticated-User: me@berkoc.com X-Sender-Address: me@berkoc.com Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" 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. A single switch on msg->vid_hdr.type then computes the type-specific payload size: the three completion-driving types (SYNTHVID_VERSION_RESPONSE, SYNTHVID_RESOLUTION_RESPONSE, SYNTHVID_VRAM_LOCATION_ACK) fall through to a shared exit that requires that size before memcpy/complete, while SYNTHVID_FEATURE_CHANGE validates its own payload and returns before reading is_dirt_needed. Unknown types are dropped. SYNTHVID_RESOLUTION_RESPONSE is variable length: the host fills resolution_count entries, not the full SYNTHVID_MAX_RESOLUTION_COUNT array. Validate the fixed prefix first so resolution_count can be read, bound it against the array, then require only the count-sized array, so the shorter responses the host actually sends are accepted. Only run the sub-handler when vmbus_recvpacket() returned success. The memcpy length is bytes_recvd, which is bounded by VMBUS_MAX_PACKET_SIZE only on a successful receive; on -ENOBUFS vmbus_recvpacket() instead reports the required length, which can exceed hv->recv_buf, so copying bytes_recvd would read and write past the 16 KiB buffers. Gating on the success return keeps the copy bounded. The nonzero-return path is itself a malformed-message case and is now logged rather than silently skipped; channel recovery is not attempted. Rejected packets are reported via drm_err_ratelimited() rather than silently dropped, matching the CoCo-hardened pattern in hv_kvp_onchannelcallback(). Fixes: 76c56a5affeb ("drm/hyperv: Add DRM driver for hyperv synthetic video= device") Cc: stable@vger.kernel.org # 5.14+ Signed-off-by: Berkant Koc Assisted-by: Claude:claude-opus-4-7 berkoc-pipeline --- drivers/gpu/drm/hyperv/hyperv_drm_proto.c | 100 +++++++++++++++++++--- 1 file changed, 87 insertions(+), 13 deletions(-) diff --git a/drivers/gpu/drm/hyperv/hyperv_drm_proto.c b/drivers/gpu/drm/hy= perv/hyperv_drm_proto.c index c3d0ff229..4e6f703a1 100644 --- a/drivers/gpu/drm/hyperv/hyperv_drm_proto.c +++ b/drivers/gpu/drm/hyperv/hyperv_drm_proto.c @@ -420,30 +420,92 @@ static int hyperv_get_supported_resolution(struct hv_= device *hdev) return 0; } =20 -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 =3D hv_get_drvdata(hdev); struct synthvid_msg *msg; + size_t hdr_size; + size_t need; =20 if (!hv) return; =20 - msg =3D (struct synthvid_msg *)hv->recv_buf; - - /* Complete the wait event */ - if (msg->vid_hdr.type =3D=3D SYNTHVID_VERSION_RESPONSE || - msg->vid_hdr.type =3D=3D SYNTHVID_RESOLUTION_RESPONSE || - msg->vid_hdr.type =3D=3D SYNTHVID_VRAM_LOCATION_ACK) { - memcpy(hv->init_buf, msg, VMBUS_MAX_PACKET_SIZE); - complete(&hv->wait); + hdr_size =3D 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; } =20 - if (msg->vid_hdr.type =3D=3D SYNTHVID_FEATURE_CHANGE) { + msg =3D (struct synthvid_msg *)hv->recv_buf; + need =3D hdr_size; + + switch (msg->vid_hdr.type) { + case SYNTHVID_VERSION_RESPONSE: + need +=3D sizeof(struct synthvid_version_resp); + break; + case SYNTHVID_RESOLUTION_RESPONSE: + /* + * The resolution response is variable length: the host + * fills resolution_count entries, not the full + * SYNTHVID_MAX_RESOLUTION_COUNT array. Require the fixed + * prefix first so resolution_count can be read, then + * demand exactly the count-sized array. + */ + need +=3D offsetof(struct synthvid_supported_resolution_resp, + supported_resolution); + if (bytes_recvd < need) + break; + if (msg->resolution_resp.resolution_count > + SYNTHVID_MAX_RESOLUTION_COUNT) { + drm_err_ratelimited(&hv->dev, + "synthvid resolution count too large: %u\n", + msg->resolution_resp.resolution_count); + return; + } + need +=3D msg->resolution_resp.resolution_count * + sizeof(struct hvd_screen_info); + break; + case SYNTHVID_VRAM_LOCATION_ACK: + need +=3D sizeof(struct synthvid_vram_location_ack); + break; + case SYNTHVID_FEATURE_CHANGE: + /* + * Not a completion-driving message: validate its own payload + * and consume it here rather than falling through to the + * memcpy/complete shared by the wait-event responses. + */ + if (bytes_recvd < need + + sizeof(struct synthvid_feature_change)) { + drm_err_ratelimited(&hv->dev, + "synthvid feature change packet too small: %u\n", + bytes_recvd); + return; + } hv->dirt_needed =3D msg->feature_chg.is_dirt_needed; if (hv->dirt_needed) hyperv_hide_hw_ptr(hv->hdev); + return; + default: + return; + } + + /* + * Shared completion path for the wait-event responses + * (VERSION_RESPONSE, RESOLUTION_RESPONSE, VRAM_LOCATION_ACK): + * require the type-specific payload before handing the buffer to + * the waiter. + */ + 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); } =20 static void hyperv_receive(void *ctx) @@ -464,9 +526,21 @@ static void hyperv_receive(void *ctx) ret =3D vmbus_recvpacket(hdev->channel, recv_buf, VMBUS_MAX_PACKET_SIZE, &bytes_recvd, &req_id); - if (bytes_recvd > 0 && - recv_buf->pipe_hdr.type =3D=3D PIPE_MSG_DATA) - hyperv_receive_sub(hdev); + if (ret) { + /* + * A nonzero return (e.g. -ENOBUFS for an oversized + * packet) is itself a malformed message: bytes_recvd + * then reports the required length rather than a copied + * payload, so it must not be forwarded to the + * sub-handler. Channel recovery is not attempted. + */ + drm_err_ratelimited(&hv->dev, + "vmbus_recvpacket failed: %d (need %u)\n", + ret, bytes_recvd); + } else if (bytes_recvd > 0 && + recv_buf->pipe_hdr.type =3D=3D PIPE_MSG_DATA) { + hyperv_receive_sub(hdev, bytes_recvd); + } } while (bytes_recvd > 0 && ret =3D=3D 0); } =20 --=20 2.47.3