Re: [PATCH net-next v5 1/3] net: stmmac: take ownership of saved RX state at poll entry

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] bpf: packet injection via dropped jumbo frames in stmmac_rx_zc
--

commit 3706267b24a396bb486058241888899e504fbd4c
Author: James Hilliard <james.hilliard1@gmail.com>

net: stmmac: take ownership of saved RX state at poll entry

This commit addresses a use-after-free issue when a saved partial packet
completes with a poll budget of one. It ensures the saved RX state is taken
at poll entry and the stored ownership is cleared immediately.

> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
[ ... ]
> @@ -5705,6 +5712,7 @@ static int stmmac_rx_zc(struct stmmac_priv *priv, int limit, u32 queue)
>  
>  		if (unlikely(error && (status & rx_not_ls)))
>  			goto read_again;
> +
>  		if (unlikely(error)) {
>  			count++;
>  			continue;
>  		}
>  
>  		/* XSK pool expects RX frame 1:1 mapped to XSK buffer */
>  		if (likely(status & rx_not_ls)) {
>  			xsk_buff_free(buf->xdp);
>  			buf->xdp = NULL;
>  			dirty++;
>  			count++;
>  			goto read_again;
>  		}

[Severity: High]
Does this code leave subsequent fragments of a dropped scattered frame
vulnerable to being processed as new, valid packets?

When a jumbo frame is split across multiple descriptors, the first descriptor
has status & rx_not_ls set. In the zero-copy path, this fragment is dropped,
and the code jumps back to read_again. However, it does not set error = 1
before doing so.

Because the error state remains 0, the error skip checks at the beginning
of the loop are bypassed when processing the next fragment of the same packet.
If that next fragment is the tail fragment (where rx_not_ls is 0), it appears
it will be erroneously processed as an independent, valid packet and passed to
the XDP program.

Could this allow an attacker to craft a jumbo frame that injects arbitrary
headers and payload into the stack?

It looks like subsequent patches in this series update the non-zero-copy
stmmac_rx path to properly accumulate fragments, but it appears stmmac_rx_zc
might have been missed and does not yet handle scattered frames or set
error = 1.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261009-stmmac-rx-mb-v5-0-c38fa4eaa138@oss.qualcomm.com?part=1