From: Michael Kelley <mhkelley58@gmail.com>
To: 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
Cc: linux-hyperv@vger.kernel.org, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org
Subject: [PATCH net 2/2] hv_netvsc: Leak send/recv buffers if GPADL teardown fails
Date: Thu, 3 Sep 2026 09:06:51 -0700 [thread overview]
Message-ID: <20260903160651.1637-3-mhklinux@outlook.com> (raw)
In-Reply-To: <20260903160651.1637-1-mhklinux@outlook.com>
If GPADL teardown fails for the send or receive buffers, the Hyper-V
host retains access to the buffers and might continue to access them.
Per the code comments, the intent is to be safe by leaking the buffers
instead of freeing them.
The intended behavior existed prior to commit 02400fcee254 ("hv_netvsc:
use RCU to fix concurrent rx and queue changes") because freeing
the buffers was done in the same function as the GPADL teardown.
The "return" statement in the error path effectively skipped freeing
the memory. But commit 02400fcee254 moved the freeing to a separate
function that is called later. It has no knowledge of the GPADL teardown
error, and so frees the memory regardless.
Fix this by calling vmbus_leak_buffer() if the respective GPADL
teardown fails. The later call to vmbus_free_buffer() then skips
freeing of the actual buffer, including any re-encryption required
in a CoCo VM.
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://lore.kernel.org/linux-hyperv/20260731201210.3653C1F00AC4@smtp.kernel.org/
Fixes: 02400fcee254 ("hv_netvsc: use RCU to fix concurrent rx and queue changes")
Signed-off-by: Michael Kelley <mhklinux@outlook.com>
---
drivers/net/hyperv/netvsc.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/net/hyperv/netvsc.c b/drivers/net/hyperv/netvsc.c
index 5cd084e5696c..449dc928cc44 100644
--- a/drivers/net/hyperv/netvsc.c
+++ b/drivers/net/hyperv/netvsc.c
@@ -316,6 +316,9 @@ 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);
netdev_err(ndev,
"unable to teardown receive buffer's gpadl\n");
return;
@@ -337,6 +340,9 @@ static void netvsc_teardown_send_gpadl(struct hv_device *device,
* rather than continue and a bugchk
*/
if (ret != 0) {
+ vmbus_leak_buffer(&net_device->send_buf,
+ &net_device->send_buf_chunks,
+ &net_device->send_buf_chunk_cnt);
netdev_err(ndev,
"unable to teardown send buffer's gpadl\n");
return;
--
2.25.1
prev parent reply other threads:[~2026-09-03 16:07 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-03 16:06 [PATCH 0/2] hv_netvsc: Fix leaking of send/receive buffers after GPADL teardown error Michael Kelley
2026-09-03 16:06 ` [PATCH 1/2] Drivers: hv: Add vmbus_leak_buffer() Michael Kelley
2026-09-03 16:06 ` Michael Kelley [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=20260903160651.1637-3-mhklinux@outlook.com \
--to=mhkelley58@gmail.com \
--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=mhklinux@outlook.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox