[PATCH net v2] net: fec: reject oversized fragments before bounce-buffer memcpy

[PATCH net v2] net: fec: reject oversized fragments before bounce-buffer memcpy

[Aldo Ariel Panzardo]

fec_enet_txq_submit_frag_skb() and fec_enet_txq_submit_skb() copy
transmit data into a per-ring bounce buffer when the source address is
misaligned or the FEC_QUIRK_SWAP_FRAME quirk is active. The bounce
buffers are allocated as kmalloc(FEC_ENET_TX_FRSIZE) where
FEC_ENET_TX_FRSIZE is 2048 bytes.

However, skb_frag_size() can return up to PAGE_SIZE (4096 on most
architectures) for scatter-gather fragments, and skb_headlen() can
exceed 2048 for certain GSO packets. When this happens the memcpy
overflows the bounce buffer by up to 2048 bytes, corrupting adjacent
heap objects.

Add a length check before each bounce-buffer copy. If the data exceeds
the bounce buffer capacity, fall through to the error path rather than
performing the out-of-bounds write.

Fixes: 6605b730c061 ("FEC: Add alignment handling for FEC driver")
Cc: stable@vger.kernel.org
Reported-by: Sashiko <sashiko-bot@kernel.org>
Signed-off-by: Aldo Ariel Panzardo <qwe.aldo@gmail.com>
---
 drivers/net/ethernet/freescale/fec_main.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
index 794ec42..8614984 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -558,6 +558,8 @@ fec_enet_txq_submit_frag_skb(struct fec_enet_priv_tx_q *txq,
 		index = fec_enet_get_bd_index(bdp, &txq->bd);
 		if (((unsigned long) bufaddr) & fep->tx_align ||
 			fep->quirks & FEC_QUIRK_SWAP_FRAME) {
+			if (frag_len > FEC_ENET_TX_FRSIZE)
+				goto dma_mapping_error;
 			memcpy(txq->tx_bounce[index], bufaddr, frag_len);
 			bufaddr = txq->tx_bounce[index];
 
@@ -634,6 +636,8 @@ static int fec_enet_txq_submit_skb(struct fec_enet_priv_tx_q *txq,
 	index = fec_enet_get_bd_index(bdp, &txq->bd);
 	if (((unsigned long) bufaddr) & fep->tx_align ||
 		fep->quirks & FEC_QUIRK_SWAP_FRAME) {
+		if (buflen > FEC_ENET_TX_FRSIZE)
+			goto release;
 		memcpy(txq->tx_bounce[index], skb->data, buflen);
 		bufaddr = txq->tx_bounce[index];
 
-- 
2.43.0

Re: [PATCH net v2] net: fec: reject oversized fragments before bounce-buffer memcpy

[Andrew Lunn]

On Wed, Sep 23, 2026 at 05:37:38PM -0300, Aldo Ariel Panzardo wrote:
> fec_enet_txq_submit_frag_skb() and fec_enet_txq_submit_skb() copy
> transmit data into a per-ring bounce buffer when the source address is
> misaligned or the FEC_QUIRK_SWAP_FRAME quirk is active.

ndev->max_mtu = fep->max_buf_size - VLAN_ETH_HLEN - ETH_FCS_LEN;

What value is this? Is it greater than, or smaller than FEC_ENET_TX_FRSIZE?

	Andrew

RE: [PATCH net v2] net: fec: reject oversized fragments before bounce-buffer memcpy

[Wei Fang]

> fec_enet_txq_submit_frag_skb() and fec_enet_txq_submit_skb() copy
> transmit data into a per-ring bounce buffer when the source address is
> misaligned or the FEC_QUIRK_SWAP_FRAME quirk is active. The bounce
> buffers are allocated as kmalloc(FEC_ENET_TX_FRSIZE) where
> FEC_ENET_TX_FRSIZE is 2048 bytes.
> 
> However, skb_frag_size() can return up to PAGE_SIZE (4096 on most
> architectures) for scatter-gather fragments, and skb_headlen() can
> exceed 2048 for certain GSO packets. When this happens the memcpy
> overflows the bounce buffer by up to 2048 bytes, corrupting adjacent
> heap objects.
> 
> Add a length check before each bounce-buffer copy. If the data exceeds
> the bounce buffer capacity, fall through to the error path rather than
> performing the out-of-bounds write.
> 
> Fixes: 6605b730c061 ("FEC: Add alignment handling for FEC driver")
> Cc: stable@vger.kernel.org
> Reported-by: Sashiko <sashiko-bot@kernel.org>
> Signed-off-by: Aldo Ariel Panzardo <qwe.aldo@gmail.com>
> ---
>  drivers/net/ethernet/freescale/fec_main.c | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/net/ethernet/freescale/fec_main.c
> b/drivers/net/ethernet/freescale/fec_main.c
> index 794ec42..8614984 100644
> --- a/drivers/net/ethernet/freescale/fec_main.c
> +++ b/drivers/net/ethernet/freescale/fec_main.c
> @@ -558,6 +558,8 @@ fec_enet_txq_submit_frag_skb(struct
> fec_enet_priv_tx_q *txq,
>  		index = fec_enet_get_bd_index(bdp, &txq->bd);
>  		if (((unsigned long) bufaddr) & fep->tx_align ||
>  			fep->quirks & FEC_QUIRK_SWAP_FRAME) {
> +			if (frag_len > FEC_ENET_TX_FRSIZE)
> +				goto dma_mapping_error;
>  			memcpy(txq->tx_bounce[index], bufaddr, frag_len);
>  			bufaddr = txq->tx_bounce[index];
> 
> @@ -634,6 +636,8 @@ static int fec_enet_txq_submit_skb(struct
> fec_enet_priv_tx_q *txq,
>  	index = fec_enet_get_bd_index(bdp, &txq->bd);
>  	if (((unsigned long) bufaddr) & fep->tx_align ||
>  		fep->quirks & FEC_QUIRK_SWAP_FRAME) {
> +		if (buflen > FEC_ENET_TX_FRSIZE)
> +			goto release;

Where is the 'release' label, I could not find it in latest net tree.

Also, do not repost a new version within 24 hours.
https://elixir.bootlin.com/linux/v7.3-rc3/source/Documentation/process/maintainer-netdev.rst#L15

Re: [PATCH net v2] net: fec: reject oversized fragments before bounce-buffer memcpy

[Andrew Lunn]

On Wed, Sep 23, 2026 at 06:22:01PM -0300, Aldo Ariel wrote:
> Hi Andrew,
> 
> PKT_MAXBUF_SIZE = round_down(2048 - 64, 64) = 1984
> max_mtu (non-jumbo) = 1984 - VLAN_ETH_HLEN - ETH_FCS_LEN = 1962
> 
> So for standard MTU, max_mtu < FEC_ENET_TX_FRSIZE and individual
> fragments should not exceed the bounce buffer.
> 
> However, when the device supports jumbo frames,
> max_buf_size = MAX_JUMBO_BUF_SIZE (~16256) and max_mtu reaches ~16234.
> Scatter-gather fragments in that case can exceed FEC_ENET_TX_FRSIZE
> while still needing the bounce path for alignment or byte-swap.
> 
> Should I respin with a check only for the jumbo path, or is the
> unconditional guard acceptable?

Can bounce buffers and jumbo be used at the same time?

How is the scatter-gather size determined? Maybe the better fix is to
set the fragment size based on the size of the bounce buffer when it
is in use?

	Andrew

Re: [PATCH net v2] net: fec: reject oversized fragments before bounce-buffer memcpy

[Shenwei Wang]

NXP Confidential
> -----Original Message-----
> From: Andrew Lunn <andrew@lunn.ch>
> Sent: Thursday, September 24, 2026 7:41 AM
> To: Aldo Ariel <qwe.aldo@gmail.com>
> Cc: Wei Fang <wei.fang@nxp.com>; Frank Li <frank.li@nxp.com>; Shenwei Wang
> <shenwei.wang@nxp.com>; imx@lists.linux.dev; netdev@vger.kernel.org; linux-
> kernel@vger.kernel.org; stable@vger.kernel.org; Sashiko <sashiko-
> bot@kernel.org>
> Subject: [EXT] Re: [PATCH net v2] net: fec: reject oversized fragments before
> bounce-buffer memcpy
>
> Caution: This is an external email. Please take care when clicking links or opening
> attachments. When in doubt, report the message using the 'Report this email'
> button
>
>
> On Wed, Sep 23, 2026 at 06:22:01PM -0300, Aldo Ariel wrote:
> > Hi Andrew,
> >
> > PKT_MAXBUF_SIZE = round_down(2048 - 64, 64) = 1984 max_mtu (non-jumbo)
> > = 1984 - VLAN_ETH_HLEN - ETH_FCS_LEN = 1962
> >
> > So for standard MTU, max_mtu < FEC_ENET_TX_FRSIZE and individual
> > fragments should not exceed the bounce buffer.
> >
> > However, when the device supports jumbo frames, max_buf_size =
> > MAX_JUMBO_BUF_SIZE (~16256) and max_mtu reaches ~16234.
> > Scatter-gather fragments in that case can exceed FEC_ENET_TX_FRSIZE
> > while still needing the bounce path for alignment or byte-swap.
> >
> > Should I respin with a check only for the jumbo path, or is the
> > unconditional guard acceptable?
>
> Can bounce buffers and jumbo be used at the same time?
>

No. Bounce buffer is only available on i.mx28.

Shenwei

> How is the scatter-gather size determined? Maybe the better fix is to set the
> fragment size based on the size of the bounce buffer when it is in use?
>
>         Andrew

Re: Re: [PATCH net v2] net: fec: reject oversized fragments before bounce-buffer memcpy

[Andrew Lunn]

On Wed, Oct 07, 2026 at 05:17:20AM -0700, Aldo Ariel wrote:
> Hi Andrew, Wei, Shenwei,
> 
> Thank you for the review. Shenwei confirmed that bounce buffers are
> only available on i.MX28 and cannot coexist with jumbo frames. That
> means the overflow path I described (jumbo fragments exceeding
> FEC_ENET_TX_FRSIZE) is not reachable in practice: on i.MX28 the
> max_mtu stays below the bounce buffer capacity.
> 
> Given that, should I respin as a defense-in-depth guard (with the
> goto label fixed per Wei's note), or would you prefer I withdraw the
> patch?

I suggest adding a comment somewhere to explain that jumbo frames and
bounce buffers are mutually exclusive by hardware design.

We don't use defensive code, because that suggests we don't actually
understand the code!

	   Andrew