All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Joshua Washington" <joshwash@google.com>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH net 1/6] gve: increment work_done for XDP and error packets
Date: Sat, 15 Aug 2026 23:49:28 +0000	[thread overview]
Message-ID: <20260815234928.77AA61F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <20260814234845.773189-2-joshwash@google.com>

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

New issues:
- [Medium] The patch inadvertently corrupts `rx->rpackets` statistics by counting descriptor errors, allocation failures, and XDP drops as successfully received packets, and creates a mismatch with `rx->rbytes`.

Pre-existing issues:
- [Critical] Missing state tracking for dropped multi-descriptor packets in the DQO RX path causes subsequent fragments to be treated as new packets, leading to payload corruption, bypass of XDP drop rules, and unsafe XDP execution on partial data.
--

--- Patch [1]: [PATCH net 1/6] gve: increment work_done for XDP and error packets ---
commit 705a50c36a672a5d7810174d670e9330d7aada5f
Author: Joshua Washington <joshwash@google.com>

gve: increment work_done for XDP and error packets

Ensure every packet is accounted for in work_done by incrementing
work_done before checking for the existence of a SKB.

Cc: stable@vger.kernel.org

> diff --git a/drivers/net/ethernet/google/gve/gve_rx_dqo.c b/drivers/net/ethernet/google/gve/gve_rx_dqo.c
> index 0ece2f6fdffb4..db38bc6452969 100644
> --- a/drivers/net/ethernet/google/gve/gve_rx_dqo.c
> +++ b/drivers/net/ethernet/google/gve/gve_rx_dqo.c
> @@ -1145,13 +1145,14 @@ int gve_rx_poll_dqo(struct gve_notify_block *block, int budget)
>  		/* Free running counter of completed descriptors */
>  		rx->cnt++;
>  
> -		if (!rx->ctx.skb_head)
> -			continue;
> -
>  		if (!compl_desc->end_of_packet)
>  			continue;

[Severity: Critical]
This is a pre-existing issue, but does the polling loop lack state tracking
for dropped multi-descriptor packets?

If a multi-fragment packet is dropped (for example, by an XDP rule
in gve_rx_dqo()), rx->ctx.skb_head remains NULL. When the loop handles the
next fragment of that same packet, it skips to it because of the
end_of_packet check.

Since skb_head is NULL, gve_rx_dqo() will treat the middle fragment as a
new packet:

drivers/net/ethernet/google/gve/gve_rx_dqo.c:gve_rx_dqo() {
        ...
        /* Append to current skb if one exists. */
        if (rx->ctx.skb_head) {
        ...
}

Can this lead to XDP programs running on partial data and malicious inner
payloads bypassing XDP drop rules?

>  		work_done++;
> +
> +		if (!rx->ctx.skb_head)
> +			continue;
> +

[Severity: Medium]
Does this change inadvertently increment the interface packet statistics
for dropped packets?

By moving the work_done increment before the skb_head check, work_done
now correctly accounts for dropped packets, XDP drops, and allocation
failures in the NAPI budget.

However, work_done is later used to update rx->rpackets at the end of
gve_rx_poll_dqo():

        u64_stats_update_begin(&rx->statss);
        rx->rpackets += work_done;
        rx->rbytes += bytes;
        u64_stats_update_end(&rx->statss);

Will this cause dropped packets to be incorrectly counted as successfully
received packets, causing the rpackets stat to diverge from rbytes?

>  		pkt_bytes = rx->ctx.skb_head->len;
>  		/* The ethernet header (first ETH_HLEN bytes) is snipped off

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260814234845.773189-1-joshwash@google.com?part=1

  reply	other threads:[~2026-08-15 23:49 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-14 23:48 [PATCH net 0/6] gve: various XDP fixes Joshua Washington
2026-08-14 23:48 ` [PATCH net 1/6] gve: increment work_done for XDP and error packets Joshua Washington
2026-08-15 23:49   ` sashiko-bot [this message]
2026-08-14 23:48 ` [PATCH net 2/6] gve: fix XSK buffer leak when rings are stopped Joshua Washington
2026-08-15 23:49   ` sashiko-bot
2026-08-14 23:48 ` [PATCH net 3/6] gve: fix XSK buffer leak on error descriptor Joshua Washington
2026-08-15 23:49   ` sashiko-bot
2026-08-14 23:48 ` [PATCH net 4/6] gve: don't register xsk pool on pre-existing queues in RDA mode Joshua Washington
2026-08-15 23:49   ` sashiko-bot
2026-08-14 23:48 ` [PATCH net 5/6] gve: fix napi_disable deadlock when attempting to disable XSK pools Joshua Washington
2026-08-15 23:49   ` sashiko-bot
2026-08-14 23:48 ` [PATCH net 6/6] gve: fix NULL dereference from premature XSK pool DMA unmap Joshua Washington
2026-08-15 23:49   ` sashiko-bot
2026-08-16  5:29 ` [PATCH net 0/6] gve: various XDP fixes Joshua Washington

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=20260815234928.77AA61F00A3A@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=joshwash@google.com \
    --cc=sashiko-reviews@lists.linux.dev \
    /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.