Re: [RESEND PATCH net-next 3/6] hv_netvsc: Remove GPADL teardown special case for old Hyper-V hosts

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] If GPADL teardown fails, the receive/send buffers are mistakenly returned to the kernel allocator via vfree() instead of being intentionally leaked, creating a guest memory corruption vulnerability (DMA-after-free).
--

--- Patch [3]: [RESEND PATCH net-next 3/6] hv_netvsc: Remove GPADL teardown special case for old Hyper-V hosts ---
commit eeed9aa2167381d7fb4f1e329217b52e4689eb18
Author: Michael Kelley <mhkelley58@gmail.com>

hv_netvsc: Remove GPADL teardown special case for old Hyper-V hosts
    
With the overall removal of Linux support for running on Hyper-V
hosts earlier than WS2016 and Windows 10, the special case handling of
GPADL teardown is no longer necessary. Remove it.

> diff --git a/drivers/net/hyperv/netvsc.c b/drivers/net/hyperv/netvsc.c
> index 4d319c50955ed..4295b96b43127 100644
> --- a/drivers/net/hyperv/netvsc.c
> +++ b/drivers/net/hyperv/netvsc.c

[ ... ]

> @@ -733,14 +724,9 @@ void netvsc_device_remove(struct hv_device *device)
>  	/* Now, we can close the channel safely */
>  	vmbus_close(device->channel);
>  
> -	/*
> -	 * If host is Win2016 or higher then we do the GPADL tear down
> -	 * here after VMBus is closed.
> -	*/
> -	if (vmbus_proto_version >= VERSION_WIN10) {
> -		netvsc_teardown_recv_gpadl(device, net_device, ndev);
> -		netvsc_teardown_send_gpadl(device, net_device, ndev);
> -	}
> +	/* Must do the GPADL teardown after channel is closed */
> +	netvsc_teardown_recv_gpadl(device, net_device, ndev);
> +	netvsc_teardown_send_gpadl(device, net_device, ndev);
>  
>  	/* Release all resources */
>  	free_netvsc_device_rcu(net_device);

[Severity: High]
This is a pre-existing issue, but I noticed a potential DMA-after-free
related to these teardown functions.

If vmbus_teardown_gpadl() fails inside netvsc_teardown_recv_gpadl() (or the
send equivalent), the code attempts to intentionally leak the buffer rather
than bugchk:

drivers/net/hyperv/netvsc.c:netvsc_teardown_recv_gpadl() {
    ...
    ret = vmbus_teardown_gpadl(device->channel,
                               &net_device->recv_buf_gpadl_handle);
    if (ret != 0) {
        netdev_err(ndev, "unable to teardown receive buffer's gpadl\n");
        return;
    }
}

However, because net_device->recv_buf isn't set to NULL on this error path,
execution continues to free_netvsc_device_rcu() just below, which ends up
unconditionally freeing it:

drivers/net/hyperv/netvsc.c:free_netvsc_device() {
    ...
    if (!nvdev->recv_buf_gpadl_handle.decrypted)
        vfree(nvdev->recv_buf);
    ...
}

Since the GPADL teardown failed, does the host still have this memory mapped
when it gets returned to the kernel allocator via vfree(), leading to
potential guest memory corruption if the host writes to it?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260730201123.1767-1-mhklinux@outlook.com?part=3