[PATCH net] xen/netfront: don't leak the skb when xennet_fill_frags() fails

[PATCH net] xen/netfront: don't leak the skb when xennet_fill_frags() fails

[Josef Bacik]

When a response chain has more slots than fit in the skb's frags,
xennet_fill_frags() returns an error and xennet_poll() jumps to its
error path.  That path moves what's left on tmpq to errq to be freed,
but the skb being filled was already dequeued from tmpq, so it's never
freed.  Each chain that overflows leaks the skb and the pages attached
to it as frags, and the backend decides how many slots it sends.

Put the skb back on tmpq before taking the error path, like the
xennet_set_skb_gso() failure just above it does.

Fixes: ad4f15dc2c70 ("xen/netfront: don't bug in case of too many frags")
Cc: stable@vger.kernel.org
Assisted-by: LLM
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
---
I found this while testing an unrelated netfront fix under QEMU's KVM
Xen emulation, with QEMU's xen_nic backend changed to spread frames
over more RX slots than netfront can fit.  kmemleak reported one
unreferenced skb from xennet_alloc_rx_buffers() for every frame that
overflowed.  With this patch the overflowing frames still take the
error path, and kmemleak no longer finds any skbs left behind by them.

Thanks,
Josef
---
 drivers/net/xen-netfront.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index 2ed673649c48..e8675bdca595 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -1338,8 +1338,10 @@ static int xennet_poll(struct napi_struct *napi, int budget)
 		skb->data_len = rx->status;
 		skb->len += rx->status;
 
-		if (unlikely(xennet_fill_frags(queue, skb, &tmpq)))
+		if (unlikely(xennet_fill_frags(queue, skb, &tmpq))) {
+			__skb_queue_head(&tmpq, skb);
 			goto err;
+		}
 
 		if (rx->flags & XEN_NETRXF_csum_blank)
 			skb->ip_summed = CHECKSUM_PARTIAL;

---
base-commit: 23609bce9e1de525d1d0e73fc68c6e7971d0b49e
change-id: 20261007-b4-xen-netfront-fill-frags-leak-357ca746de6b

Re: [PATCH net] xen/netfront: don't leak the skb when xennet_fill_frags() fails

[Juergen Gross]

[-- Attachment #1.1.1: Type: text/plain, Size: 836 bytes --]

On 07.10.26 19:57, Josef Bacik wrote:
> When a response chain has more slots than fit in the skb's frags,
> xennet_fill_frags() returns an error and xennet_poll() jumps to its
> error path.  That path moves what's left on tmpq to errq to be freed,
> but the skb being filled was already dequeued from tmpq, so it's never
> freed.  Each chain that overflows leaks the skb and the pages attached
> to it as frags, and the backend decides how many slots it sends.
> 
> Put the skb back on tmpq before taking the error path, like the
> xennet_set_skb_gso() failure just above it does.
> 
> Fixes: ad4f15dc2c70 ("xen/netfront: don't bug in case of too many frags")
> Cc: stable@vger.kernel.org
> Assisted-by: LLM
> Signed-off-by: Josef Bacik <josef@toxicpanda.com>

Reviewed-by: Juergen Gross <jgross@suse.com>


Juergen

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3743 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

Re: [PATCH net] xen/netfront: don't leak the skb when xennet_fill_frags() fails

[patchwork-bot+netdevbpf]

Hello:

This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:

On Wed, 07 Oct 2026 17:57:32 +0000 you wrote:
> When a response chain has more slots than fit in the skb's frags,
> xennet_fill_frags() returns an error and xennet_poll() jumps to its
> error path.  That path moves what's left on tmpq to errq to be freed,
> but the skb being filled was already dequeued from tmpq, so it's never
> freed.  Each chain that overflows leaks the skb and the pages attached
> to it as frags, and the backend decides how many slots it sends.
> 
> [...]

Here is the summary with links:
  - [net] xen/netfront: don't leak the skb when xennet_fill_frags() fails
    https://git.kernel.org/netdev/net/c/93ccaf1c26e2

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html