Re: [PATCH net-next v8 13/15] net: lan966x: add PCIe FDMA XDP support

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] net: XDP program shrinking frame below ETH_HLEN causes OOB read in eth_type_trans()
--

commit 65038b88aa7eb3b2b7d79cb17c606497fae0582c
Author: Daniel Machon <daniel.machon@microchip.com>

net: lan966x: add PCIe FDMA XDP support

This commit adds XDP support for the PCIe FDMA path in the lan966x driver.
The implementation operates on contiguous ATU-mapped buffers with
memcpy-based XDP_TX, and updates the receive path to handle frame lengths
returned by the XDP program.

> diff --git a/drivers/net/ethernet/microchip/lan966x/lan966x_fdma_pci.c b/drivers/net/ethernet/microchip/lan966x/lan966x_fdma_pci.c
> index 7185e65dda435..216e9cbcd1580 100644
> --- a/drivers/net/ethernet/microchip/lan966x/lan966x_fdma_pci.c
> +++ b/drivers/net/ethernet/microchip/lan966x/lan966x_fdma_pci.c
[ ... ]
> @@ -136,7 +138,123 @@ static bool lan966x_fdma_pci_rx_size_fits(struct fdma *fdma, u32 blockl)
[ ... ]
> +static int lan966x_xdp_pci_run(struct lan966x_port *port, void *data,
> +			       u32 data_len, void **xdp_data, u32 *xdp_len)
> +{
[ ... ]
> +	act = bpf_prog_run_xdp(xdp_prog, &xdp);
> +
> +	*xdp_data = xdp.data;
> +	*xdp_len = xdp.data_end - xdp.data;
> +
> +	switch (act) {
> +	case XDP_PASS:
> +		return FDMA_PASS;

[Severity: High]
Does this code allow an XDP program to shrink the frame size below the
minimum Ethernet header size (ETH_HLEN)?

If the loaded XDP program shrinks the packet and returns XDP_PASS,
the modified length is accepted here and passed along to the driver's
receive handling without bounds checking to ensure it is at least ETH_HLEN.

[ ... ]
> @@ -168,38 +286,33 @@ static int lan966x_fdma_pci_rx_check_frame(struct lan966x_rx *rx, u64 *src_port)
[ ... ]
>  static struct sk_buff *lan966x_fdma_pci_rx_get_frame(struct lan966x_rx *rx,
> -						     u64 src_port)
> +						     u64 src_port, void *data,
> +						     u32 data_len)
>  {
[ ... ]
> -	memcpy(skb->data,
> -	       fdma_dataptr_virt_addr_contiguous(fdma,
> -						 fdma->dcb_index,
> -						 fdma->db_index),
> -						 data_len);
> +	memcpy(skb->data, data, data_len);
>  
>  	skb_put(skb, data_len);
>  
>  	skb->dev = lan966x->ports[src_port]->dev;
> -	skb_pull(skb, IFH_LEN_BYTES);
> -
> -	skb_trim(skb, skb->len - ETH_FCS_LEN);
>  
>  	skb->protocol = eth_type_trans(skb, skb->dev);

[Severity: High]
If data_len was shrunk below ETH_HLEN by the XDP program, will this sequence
cause an out-of-bounds read and potential kernel crash?

eth_type_trans() unconditionally pulls ETH_HLEN bytes from the SKB. Passing
a truncated data_len < ETH_HLEN to skb_put() followed by eth_type_trans()
will read uninitialized memory and can corrupt skb boundaries.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260924-lan966x-pci-fdma-v8-0-201c7b707d8b@microchip.com?part=13