From: Simon Horman <horms@kernel.org>
To: mhkelley58@gmail.com
Cc: Simon Horman <horms@kernel.org>,
kys@microsoft.com, haiyangz@microsoft.com, wei.liu@kernel.org,
decui@microsoft.com, longli@microsoft.com, andrew+netdev@lunn.ch,
davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, linux-hyperv@vger.kernel.org,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: [PATCH v2 3/3] hv_netvsc: Leak send/recv buffers if GPADL teardown fails
Date: Wed, 9 Sep 2026 17:08:05 +0100 [thread overview]
Message-ID: <20260909160805.698511-1-horms@kernel.org> (raw)
In-Reply-To: <20260907214902.9046-4-mhklinux@outlook.com>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
Full review at: https://sashiko.dev/#/patchset/20260907214902.9046-2-mhklinux@outlook.com?part=3
---
hv_netvsc: Leak send/recv buffers if GPADL teardown fails
This commit addresses a bug where send/recv buffers were improperly freed if
GPADL teardown failed. It introduces calls to vmbus_leak_buffer() to safely
leak the buffers instead of freeing them when they might still be accessed by
the host.
Closes: https://lore.kernel.org/linux-hyperv/20260731201210.3653C1F00AC4@smtp.kernel.org/
> diff --git a/drivers/net/hyperv/netvsc.c b/drivers/net/hyperv/netvsc.c
> index 5cd084e5696cd..e9292c3fac925 100644
> --- a/drivers/net/hyperv/netvsc.c
> +++ b/drivers/net/hyperv/netvsc.c
> @@ -316,9 +316,11 @@ static void netvsc_teardown_recv_gpadl(struct hv_device *device,
> * rather than continue and a bugchk
> */
> if (ret != 0) {
> + vmbus_leak_buffer(&net_device->recv_buf,
> + &net_device->recv_buf_chunks,
> + &net_device->recv_buf_chunk_cnt);
[Severity: High]
Could this lead to a NULL pointer dereference if NAPI is still polling
concurrently?
In netvsc_device_add(), NAPI is enabled and the VMBus channel is opened. If a
subsequent initialization step fails (like send_buf setup), the error path
calls netvsc_teardown_recv_gpadl().
If the GPADL teardown fails, vmbus_leak_buffer() will set
net_device->recv_buf to NULL. Because NAPI is not synchronized with this
teardown and is disabled later in the error path, a concurrent softirq could
execute this path in netvsc_receive():
char *recv_buf = net_device->recv_buf;
...
data = recv_buf + offset;
...
ret = rndis_filter_receive(ndev, net_device, nvchan, data, buflen);
Since the code does not check for NULL, it passes the faulty data pointer
(NULL + offset) to rndis_filter_receive().
This would result in a kernel panic when trying to read from the pointer:
memcpy(rndis_msg, data, RNDIS_HEADER_SIZE);
Is there a way to defer setting recv_buf to NULL until after NAPI has been
disabled?
> netdev_err(ndev,
> "unable to teardown receive buffer's gpadl\n");
> - return;
> }
> }
> }
prev parent reply other threads:[~2026-09-09 16:08 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-07 21:48 [PATCH v2 0/3] hv_netvsc: Fix leaking of send/receive buffers after GPADL teardown error Michael Kelley
2026-09-07 21:49 ` [PATCH v2 1/3] Drivers: hv: vmbus: Fix error paths in vmbus_teardown_gpadl() Michael Kelley
2026-09-08 21:49 ` sashiko-bot
2026-09-09 16:07 ` Simon Horman
2026-09-07 21:49 ` [PATCH v2 2/3] Drivers: hv: Add vmbus_leak_buffer() Michael Kelley
2026-09-07 21:49 ` [PATCH v2 3/3] hv_netvsc: Leak send/recv buffers if GPADL teardown fails Michael Kelley
2026-09-08 21:49 ` sashiko-bot
2026-09-09 16:08 ` Simon Horman [this message]
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=20260909160805.698511-1-horms@kernel.org \
--to=horms@kernel.org \
--cc=andrew+netdev@lunn.ch \
--cc=davem@davemloft.net \
--cc=decui@microsoft.com \
--cc=edumazet@google.com \
--cc=haiyangz@microsoft.com \
--cc=kuba@kernel.org \
--cc=kys@microsoft.com \
--cc=linux-hyperv@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=longli@microsoft.com \
--cc=mhkelley58@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--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.