All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Nicolai Buchwitz" <nb@tipi-net.de>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH net-next v9 7/7] net: bcmgenet: reject MTU changes incompatible with XDP
Date: Thu, 07 May 2026 19:18:00 +0000	[thread overview]
Message-ID: <20260507191800.82882C2BCB2@smtp.kernel.org> (raw)
In-Reply-To: <20260506095553.55357-8-nb@tipi-net.de>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The introduced `ndo_change_mtu` callback is entirely dead code based on a false premise.
--

commit 4a63ea349d9dde80e552364564a8fc480bce7552
Author: Nicolai Buchwitz <nb@tipi-net.de>

net: bcmgenet: reject MTU changes incompatible with XDP

Add a minimal ndo_change_mtu that rejects MTU values too large for
single-page XDP buffers when an XDP program is attached.

> diff --git a/drivers/net/ethernet/broadcom/genet/bcmgenet.c b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
> --- a/drivers/net/ethernet/broadcom/genet/bcmgenet.c
> +++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
> @@ -4095,6 +4095,20 @@ static int bcmgenet_xdp_xmit(struct net_device *dev, int num_frames,
[ ... ]
> +static int bcmgenet_change_mtu(struct net_device *dev, int new_mtu)
> +{
> +	struct bcmgenet_priv *priv = netdev_priv(dev);
> +
> +	if (priv->xdp_prog && new_mtu > PAGE_SIZE - GENET_RX_HEADROOM -
> +	    SKB_DATA_ALIGN(sizeof(struct skb_shared_info))) {

Is this check actually reachable?

The networking core (dev_validate_mtu()) strictly enforces that any
requested MTU cannot exceed dev->max_mtu. Because the bcmgenet driver
does not manually override dev->max_mtu, it inherits the default value
of ETH_DATA_LEN (1500 bytes) set by ether_setup().

On a system with the minimum 4KB page size, the right side of this
condition evaluates to approximately 3400 bytes. Since new_mtu is
strictly bounded to 1500, the condition new_mtu > ~3400 seems
mathematically impossible to satisfy, rendering the check dead code.

Additionally, the driver statically configures the hardware MAC to a
maximum frame length of 1522 bytes (ENET_MAX_MTU_SIZE) and the DMA ring
to a maximum receive buffer length of 2048 bytes (RX_BUF_LENGTH). Thus,
a buffer overflow rewriting the skb_shared_info appears structurally
impossible even if the MTU check were somehow bypassed.

> +		netdev_warn(dev, "MTU too large for single-page XDP buffer\n");
> +		return -EINVAL;
> +	}
> +
> +	WRITE_ONCE(dev->mtu, new_mtu);
> +	return 0;
> +}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260506095553.55357-1-nb@tipi-net.de?part=7

      reply	other threads:[~2026-05-07 19:18 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-06  9:55 [PATCH net-next v9 0/7] net: bcmgenet: add XDP support Nicolai Buchwitz
2026-05-06  9:55 ` [PATCH net-next v9 1/7] net: bcmgenet: convert RX path to page_pool Nicolai Buchwitz
2026-05-07 19:17   ` sashiko-bot
2026-05-10 18:46   ` Jakub Kicinski
2026-05-06  9:55 ` [PATCH net-next v9 2/7] net: bcmgenet: register xdp_rxq_info for each RX ring Nicolai Buchwitz
2026-05-06  9:55 ` [PATCH net-next v9 3/7] net: bcmgenet: add basic XDP support (PASS/DROP) Nicolai Buchwitz
2026-05-07 19:17   ` sashiko-bot
2026-05-10 18:47   ` Jakub Kicinski
2026-05-06  9:55 ` [PATCH net-next v9 4/7] net: bcmgenet: add XDP_TX support Nicolai Buchwitz
2026-05-07 19:17   ` sashiko-bot
2026-05-10 18:52   ` Jakub Kicinski
2026-05-06  9:55 ` [PATCH net-next v9 5/7] net: bcmgenet: add XDP_REDIRECT and ndo_xdp_xmit support Nicolai Buchwitz
2026-05-07 19:17   ` sashiko-bot
2026-05-10 18:55   ` Jakub Kicinski
2026-05-06  9:55 ` [PATCH net-next v9 6/7] net: bcmgenet: add XDP statistics counters Nicolai Buchwitz
2026-05-07 19:17   ` sashiko-bot
2026-05-06  9:55 ` [PATCH net-next v9 7/7] net: bcmgenet: reject MTU changes incompatible with XDP Nicolai Buchwitz
2026-05-07 19:18   ` sashiko-bot [this message]

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=20260507191800.82882C2BCB2@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=nb@tipi-net.de \
    --cc=sashiko@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.