Re: [PATCH net-next v9 11/15] net: lan966x: add PCIe FDMA support

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] net: missing length validation in hardware offload checks leads to OOB read
--

commit 0077ede3c2cac9977be6b338e3fa7c1952aabe74
Author: Daniel Machon <daniel.machon@microchip.com>

net: lan966x: add PCIe FDMA support

Add PCIe FDMA support for lan966x. The PCIe FDMA path uses contiguous
DMA buffers mapped through the endpoint's ATU, with memcpy-based frame
transfer instead of per-page DMA mappings.

> diff --git a/drivers/net/ethernet/microchip/lan966x/lan966x_fdma_pci.c b/drivers/net/ethernet/microchip/lan966x/lan966x_fdma_pci.c
> new file mode 100644
> index 0000000000000..f511e70613141
> --- /dev/null
> +++ b/drivers/net/ethernet/microchip/lan966x/lan966x_fdma_pci.c
[ ... ]
> @@ -0,0 +1,458 @@
[ ... ]
> +static bool lan966x_fdma_pci_hw_offload(struct lan966x *lan966x, u32 port,
> +					struct sk_buff **pskb)
> +{
> +	struct sk_buff *skb = *pskb;
> +	u32 val;
> +
> +	val = lan_rd(lan966x, ANA_CPU_FWD_CFG(port));
> +	if (!(val & (ANA_CPU_FWD_CFG_IGMP_REDIR_ENA |
> +		     ANA_CPU_FWD_CFG_MLD_REDIR_ENA)))
> +		return true;
> +
> +	if (eth_type_vlan(skb->protocol)) {
> +		skb = skb_vlan_untag(skb);
> +		*pskb = skb;
> +		if (unlikely(!skb))
> +			return false;
> +	}
> +
> +	if (skb->protocol == htons(ETH_P_IP) &&
> +	    ip_hdr(skb)->protocol == IPPROTO_IGMP)
> +		return false;

[Severity: Medium]
Does this code safely handle truncated packets? If a remote attacker sends a
truncated IPv4 packet (e.g., a 14-byte Ethernet frame with the ETH_P_IP
ethertype) to the interface, eth_type_trans() consumes the MAC header, leaving
skb->len == 0.

Calling ip_hdr(skb)->protocol without first validating that the SKB payload
contains a complete IPv4 header would read past the valid payload. This
out-of-bounds read could access uninitialized SKB memory padding, leading to
unpredictable forwarding decisions.

Should there be a length check before dereferencing the IP header here?

(Note: This is a pre-existing issue in the original lan966x_hw_offload()
function in lan966x_main.c, which appears to have been duplicated here.)

> +
> +	if (IS_ENABLED(CONFIG_IPV6) &&
> +	    skb->protocol == htons(ETH_P_IPV6) &&
> +	    ipv6_addr_is_multicast(&ipv6_hdr(skb)->daddr) &&
> +	    !ipv6_mc_check_mld(skb))
> +		return false;

[Severity: Medium]
Similarly, does this IPv6 code path require a length validation before
accessing ipv6_hdr(skb)->daddr?

> +
> +	return true;
> +}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260928-lan966x-pci-fdma-v9-0-a17caf60f89a@microchip.com?part=11