Re: [PATCH v2 1/6] Drivers: hv: Remove support for WS2012/2012R2 & Win8/8.1 version of Hyper-V

[email protected] Wed, 05 Aug 2026 20:58:06 +0000
Newsgroups org.kernel.vger.linux-hyperv
Message-ID <[email protected]>
Thank you for your contribution! Sashiko AI review found 5 potential issue(=
s) to consider:

New issues:
- [Low] Unreachable version negotiation fallback logic left in hv_balloon.c.
- [Low] Embedded newline and multi-line string literal continuation breaks =
kernel log formatting.
- [Low] The patch series missed removing legacy VMBus version checks for VE=
RSION_WIN8 and VERSION_WIN8_1 in other Hyper-V subsystem drivers.

Pre-existing issues:
- [High] The error path in vmbus_connect() and vmbus_exit() bypasses sendin=
g the VMBus disconnect message, risking guest memory corruption.
- [High] The error paths in balloon_probe() and balloon_resume() fail to ca=
ncel scheduled work items, leading to use-after-free.
--

--- Patch [1]: [PATCH v2 1/6] Drivers: hv: Remove support for WS2012/2012R2=
 & Win8/8.1 version of Hyper-V ---
commit 764adf4bdf08e43be943c35b8558657a532f1362
Author: Michael Kelley <[email protected]>
Subject: Drivers: hv: Remove support for WS2012/2012R2 & Win8/8.1 version o=
f Hyper-V

This commit simplifies Linux code by removing special cases and VMBus
protocol version negotiations for running on older versions of Hyper-V
(WS2012/2012R2 and Windows 8/8.1), as their official support ended.

Note: The format of this report is altered due to recitation restrictions.
The original patch code is not quoted directly, but rather a free-form summ=
ary
of the issues is provided without inline quoting.

[Severity: Low]
In drivers/hv/hv_balloon.c, within the version_resp() function, the patch
hardcodes dm->next_version to 0. Is it necessary to leave the check "if
(dm->next_version =3D=3D 0) goto version_error;" and the subsequent version
request packet sending logic intact? Since the downgrade path is removed, t=
his
makes the remainder of the function mathematically unreachable dead code.

[Severity: Low]
In drivers/hv/connection.c, within the vmbus_connect() function, the patch
adds a pr_err() call for unsupported VMBus versions. Does the embedded
newline and multi-line string literal continuation break kernel log
formatting? This can cause the second line to lack a severity prefix and
interleave with other logs.

[Severity: High]
This is a pre-existing issue, but in drivers/hv/connection.c during the
vmbus_connect() error path (cleanup label), the vmbus_connection.conn_state
is explicitly set to DISCONNECTED before calling vmbus_disconnect().=20

In drivers/hv/channel_mgmt.c:vmbus_initiate_unload(), the code returns early
if the old state is DISCONNECTED or CONNECTING, thereby skipping the vital
UNLOAD message.

Can this bypass of the VMBus disconnect message cause guest memory corrupti=
on?
Since vmbus_disconnect() frees int_page and monitor_pages without the host
being notified of the teardown, the host might continue to DMA incoming
messages to these freed guest physical pages.

[Severity: High]
This is a pre-existing issue, but in drivers/hv/hv_balloon.c:balloon_probe(=
),
if the kthread_run() fails, the probe function jumps to the probe_error lab=
el.
This cleans up the VMBus channel but fails to call cancel_work_sync().=20

Since the host can send a DM_BALLOON_REQUEST which queues balloon_wrk right
after balloon_connect_vsp() finishes, can these orphaned background work
items execute later and dereference the freed device, leading to a
use-after-free?

[Severity: Low]
The patch series removed legacy VMBus version checks in the core, but did it
miss removing them in other Hyper-V subsystem drivers?=20

Drivers like drivers/gpu/drm/hyperv/hyperv_drm_proto.c (in
hv_drm_connect_vsp()) and drivers/scsi/storvsc_drv.c (in
storvsc_sdev_configure()) still contain switch cases for VERSION_WIN8 and
VERSION_WIN8_1 (or VMSTOR_PROTO_VERSION_WIN8). Since vmbus_connect() now
rejects hosts not supporting at least VERSION_WIN10, isn't this leftover
dead code?

--=20
Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260805203751.2678=
[email protected]?part=3D1