[PATCH] rtase: Workaround for IP fragmented UDP packet hardware bug

[PATCH] rtase: Workaround for IP fragmented UDP packet hardware bug

[Justin Lai]

The hardware parser incorrectly interprets 319/320 in a short
IP fragmented UDP packet payload as standard PTP destination
ports and treats the fragment as a PTP packet for further
parsing.

If the transport data is smaller than RTASE_MIN_PAD_LEN, the
remaining data is insufficient for further parsing and causes
hardware TX hang.

Pad these packets so the transport data reaches
RTASE_MIN_PAD_LEN before transmitting to avoid triggering the
hardware issue.

Signed-off-by: Justin Lai <justinlai0215@realtek.com>
---
 drivers/net/ethernet/realtek/rtase/rtase.h    |  3 ++
 .../net/ethernet/realtek/rtase/rtase_main.c   | 50 +++++++++++++++++++
 2 files changed, 53 insertions(+)

diff --git a/drivers/net/ethernet/realtek/rtase/rtase.h b/drivers/net/ethernet/realtek/rtase/rtase.h
index 9bd6872474c1..213fe2173b40 100644
--- a/drivers/net/ethernet/realtek/rtase/rtase.h
+++ b/drivers/net/ethernet/realtek/rtase/rtase.h
@@ -363,4 +363,7 @@ struct rtase_private {
 
 #define RTASE_MSS_MASK GENMASK(28, 18)
 
+#define RTASE_MIN_PAD_LEN      47
+#define RTASE_SHORT_PKT_THRESH 128
+
 #endif /* RTASE_H */
diff --git a/drivers/net/ethernet/realtek/rtase/rtase_main.c b/drivers/net/ethernet/realtek/rtase/rtase_main.c
index bde9bccfb5a9..43a4aa275b62 100644
--- a/drivers/net/ethernet/realtek/rtase/rtase_main.c
+++ b/drivers/net/ethernet/realtek/rtase/rtase_main.c
@@ -61,6 +61,7 @@
 #include <linux/pci.h>
 #include <linux/pm_runtime.h>
 #include <linux/prefetch.h>
+#include <linux/ptp_classify.h>
 #include <linux/rtnetlink.h>
 #include <linux/tcp.h>
 #include <asm/irq.h>
@@ -1250,6 +1251,52 @@ static u32 rtase_tx_csum(struct sk_buff *skb, const struct net_device *dev)
 	return csum_cmd;
 }
 
+static bool rtase_skb_is_udp(struct sk_buff *skb)
+{
+	int no = skb_network_offset(skb);
+	struct ipv6hdr *i6h, _i6h;
+	struct iphdr *ih, _ih;
+
+	switch (vlan_get_protocol(skb)) {
+	case htons(ETH_P_IP):
+		ih = skb_header_pointer(skb, no, sizeof(_ih), &_ih);
+		return ih && ih->protocol == IPPROTO_UDP;
+	case htons(ETH_P_IPV6):
+		i6h = skb_header_pointer(skb, no, sizeof(_i6h), &_i6h);
+		return i6h && i6h->nexthdr == IPPROTO_UDP;
+	default:
+		return false;
+	}
+}
+
+static bool rtase_skb_pad(struct sk_buff *skb)
+{
+	bool has_trans = skb_transport_header_was_set(skb);
+	u32 pkt_len = skb->len;
+	u32 trans_data_len;
+	u16 dest_port;
+	u32 pad_len;
+
+	if (!(has_trans &&
+	      pkt_len < RTASE_SHORT_PKT_THRESH + RTASE_MIN_PAD_LEN &&
+	      rtase_skb_is_udp(skb)))
+		return true;
+
+	trans_data_len = skb_tail_pointer(skb) - skb_transport_header(skb);
+	if (trans_data_len >= offsetof(struct udphdr, len) &&
+	    trans_data_len < RTASE_MIN_PAD_LEN) {
+		dest_port = ntohs(udp_hdr(skb)->dest);
+
+		if (dest_port == PTP_EV_PORT || dest_port == PTP_GEN_PORT) {
+			pad_len = RTASE_MIN_PAD_LEN - trans_data_len;
+			if (__skb_put_padto(skb, skb->len + pad_len, false))
+				return false;
+		}
+	}
+
+	return true;
+}
+
 static int rtase_xmit_frags(struct rtase_ring *ring, struct sk_buff *skb,
 			    u32 opts1, u32 opts2)
 {
@@ -1363,6 +1410,9 @@ static netdev_tx_t rtase_start_xmit(struct sk_buff *skb,
 		opts2 |= rtase_tx_csum(skb, dev);
 	}
 
+	if (!rtase_skb_pad(skb))
+		goto err_dma_0;
+
 	frags = rtase_xmit_frags(ring, skb, opts1, opts2);
 	if (unlikely(frags < 0))
 		goto err_dma_0;
-- 
2.40.1

Re: [PATCH] rtase: Workaround for IP fragmented UDP packet hardware bug

[Andrew Lunn]

On Mon, Jun 01, 2026 at 02:23:41PM +0800, Justin Lai wrote:
> The hardware parser incorrectly interprets 319/320 in a short
> IP fragmented UDP packet payload as standard PTP destination
> ports and treats the fragment as a PTP packet for further
> parsing.
> 
> If the transport data is smaller than RTASE_MIN_PAD_LEN, the
> remaining data is insufficient for further parsing and causes
> hardware TX hang.

Where does RTASE_SHORT_PKT_THRESH come into this?

RTASE_MIN_PAD_LEN is 47, so matches all packets which need padding up
to 60 bytes, plus FCS. There are not many such packets, so why both
this all the complexity and just pad all small packets? Do you have
any performance numbers which show the complexity is worth it?

> Pad these packets so the transport data reaches
> RTASE_MIN_PAD_LEN before transmitting to avoid triggering the
> hardware issue.
> 
> Signed-off-by: Justin Lai <justinlai0215@realtek.com>

Is this a Fix? Please add a Fixes: tag. And base it on net.

https://www.kernel.org/doc/html/latest/process/maintainer-netdev.html

    Andrew

---
pw-bot: cr

RE: [PATCH] rtase: Workaround for IP fragmented UDP packet hardware bug

[Justin Lai]

Andrew Lunn <andrew@lunn.ch> wrote:
> 
> On Mon, Jun 01, 2026 at 02:23:41PM +0800, Justin Lai wrote:
> > The hardware parser incorrectly interprets 319/320 in a short IP
> > fragmented UDP packet payload as standard PTP destination ports and
> > treats the fragment as a PTP packet for further parsing.
> >
> > If the transport data is smaller than RTASE_MIN_PAD_LEN, the remaining
> > data is insufficient for further parsing and causes hardware TX hang.
> 
> Where does RTASE_SHORT_PKT_THRESH come into this?
> 
> RTASE_MIN_PAD_LEN is 47, so matches all packets which need padding up to
> 60 bytes, plus FCS. There are not many such packets, so why both this all the
> complexity and just pad all small packets? Do you have any performance
> numbers which show the complexity is worth it?
> 
> > Pad these packets so the transport data reaches RTASE_MIN_PAD_LEN
> > before transmitting to avoid triggering the hardware issue.
> >
> > Signed-off-by: Justin Lai <justinlai0215@realtek.com>
> 
> Is this a Fix? Please add a Fixes: tag. And base it on net.
> 
> https://www.kernel.org/doc/html/latest/process/maintainer-netdev.html
> 
>     Andrew
> 
> ---
> pw-bot: cr

Hi Andrew,
 
RTASE_MIN_PAD_LEN is not the Ethernet minimum-frame padding
threshold. It is the minimum transport-data length required by
the hardware parser after the packet is incorrectly detected as
a PTP packet.
 
Therefore, this workaround needs to pad the packets which can
trigger the hardware issue, rather than just padding packets to
the Ethernet minimum frame size.
 
I agree that RTASE_SHORT_PKT_THRESH is not necessary here. I
will remove it in the next revision.
 
Yes, this is a fix. I will add a Fixes tag and repost it
against the net tree.
 
Thanks,
Justin

Re: [PATCH] rtase: Workaround for IP fragmented UDP packet hardware bug

[David Laight]

On Thu, 4 Jun 2026 08:33:51 +0000
Justin Lai <justinlai0215@realtek.com> wrote:

> Andrew Lunn <andrew@lunn.ch> wrote:
> > 
> > On Mon, Jun 01, 2026 at 02:23:41PM +0800, Justin Lai wrote:  
> > > The hardware parser incorrectly interprets 319/320 in a short IP
> > > fragmented UDP packet payload as standard PTP destination ports and
> > > treats the fragment as a PTP packet for further parsing.

Is that a packet that has been segmented by IP, or one where the skb
is fragmented enough that the data in the header is too short?
I thought that IPv4 required an mtu of 128 bytes (ish) and IPv6 somewhat
larger - so I don't see how that is a problem.

If the skb is fragmented then you need to move data into the header
not pad the frame.

If the hardware really is broken then I suspect you need to disable
the feature and suffer the consequences.

> > >
> > > If the transport data is smaller than RTASE_MIN_PAD_LEN, the remaining
> > > data is insufficient for further parsing and causes hardware TX hang.  
> > 
> > Where does RTASE_SHORT_PKT_THRESH come into this?
> > 
> > RTASE_MIN_PAD_LEN is 47, so matches all packets which need padding up to
> > 60 bytes, plus FCS. There are not many such packets, so why both this all the
> > complexity and just pad all small packets? Do you have any performance
> > numbers which show the complexity is worth it?
> >   
> > > Pad these packets so the transport data reaches RTASE_MIN_PAD_LEN
> > > before transmitting to avoid triggering the hardware issue.
> > >
> > > Signed-off-by: Justin Lai <justinlai0215@realtek.com>  
> > 
> > Is this a Fix? Please add a Fixes: tag. And base it on net.
> > 
> > https://www.kernel.org/doc/html/latest/process/maintainer-netdev.html
> > 
> >     Andrew
> > 
> > ---
> > pw-bot: cr  
> 
> Hi Andrew,
>  
> RTASE_MIN_PAD_LEN is not the Ethernet minimum-frame padding
> threshold. It is the minimum transport-data length required by
> the hardware parser after the packet is incorrectly detected as
> a PTP packet.
>  
> Therefore, this workaround needs to pad the packets which can
> trigger the hardware issue, rather than just padding packets to
> the Ethernet minimum frame size.

Is that a longer length?
Excessive frame padding (beyond 60+FCS) can be treated as a protocol error.

-- David

>  
> I agree that RTASE_SHORT_PKT_THRESH is not necessary here. I
> will remove it in the next revision.
>  
> Yes, this is a fix. I will add a Fixes tag and repost it
> against the net tree.
>  
> Thanks,
> Justin
> 

RE: [PATCH] rtase: Workaround for IP fragmented UDP packet hardware bug

[Justin Lai]

David Laight <david.laight.linux@gmail.com> wrote:
> 
> On Thu, 4 Jun 2026 08:33:51 +0000
> Justin Lai <justinlai0215@realtek.com> wrote:
> 
> > Andrew Lunn <andrew@lunn.ch> wrote:
> > >
> > > On Mon, Jun 01, 2026 at 02:23:41PM +0800, Justin Lai wrote:
> > > > The hardware parser incorrectly interprets 319/320 in a short IP
> > > > fragmented UDP packet payload as standard PTP destination ports
> > > > and treats the fragment as a PTP packet for further parsing.
> 
> Is that a packet that has been segmented by IP, or one where the skb is
> fragmented enough that the data in the header is too short?
> I thought that IPv4 required an mtu of 128 bytes (ish) and IPv6 somewhat
> larger - so I don't see how that is a problem.
> 
> If the skb is fragmented then you need to move data into the header not pad
> the frame.
> 
> If the hardware really is broken then I suspect you need to disable the feature
> and suffer the consequences.
> 
> > > >
> > > > If the transport data is smaller than RTASE_MIN_PAD_LEN, the
> > > > remaining data is insufficient for further parsing and causes hardware TX
> hang.
> > >
> > > Where does RTASE_SHORT_PKT_THRESH come into this?
> > >
> > > RTASE_MIN_PAD_LEN is 47, so matches all packets which need padding
> > > up to
> > > 60 bytes, plus FCS. There are not many such packets, so why both
> > > this all the complexity and just pad all small packets? Do you have
> > > any performance numbers which show the complexity is worth it?
> > >
> > > > Pad these packets so the transport data reaches RTASE_MIN_PAD_LEN
> > > > before transmitting to avoid triggering the hardware issue.
> > > >
> > > > Signed-off-by: Justin Lai <justinlai0215@realtek.com>
> > >
> > > Is this a Fix? Please add a Fixes: tag. And base it on net.
> > >
> > > https://www.kernel.org/doc/html/latest/process/maintainer-netdev.htm
> > > l
> > >
> > >     Andrew
> > >
> > > ---
> > > pw-bot: cr
> >
> > Hi Andrew,
> >
> > RTASE_MIN_PAD_LEN is not the Ethernet minimum-frame padding
> threshold.
> > It is the minimum transport-data length required by the hardware
> > parser after the packet is incorrectly detected as a PTP packet.
> >
> > Therefore, this workaround needs to pad the packets which can trigger
> > the hardware issue, rather than just padding packets to the Ethernet
> > minimum frame size.
> 
> Is that a longer length?
> Excessive frame padding (beyond 60+FCS) can be treated as a protocol error.
> 
> -- David
> 
> >
> > I agree that RTASE_SHORT_PKT_THRESH is not necessary here. I will
> > remove it in the next revision.
> >
> > Yes, this is a fix. I will add a Fixes tag and repost it against the
> > net tree.
> >
> > Thanks,
> > Justin
> >

Hi David,
 
This is an IP fragmented packet, not a fragmented skb.
 
The issue occurs on a non-initial IP fragment whose payload
contains values matching the PTP event/general destination
ports (319/320). The hardware parser incorrectly identifies the
fragment as a PTP packet and attempts further parsing.
 
The workaround does not modify the IP or UDP length fields. The
original protocol headers still describe the actual packet size.
 
Therefore, the protocol-defined payload size remains unchanged.
 
We have tested this workaround and have not observed issues
caused by the additional padding.
 
Thanks,
Justin

Re: [PATCH] rtase: Workaround for IP fragmented UDP packet hardware bug

[David Laight]

On Thu, 4 Jun 2026 13:43:27 +0000
Justin Lai <justinlai0215@realtek.com> wrote:

> David Laight <david.laight.linux@gmail.com> wrote:
> > 
> > On Thu, 4 Jun 2026 08:33:51 +0000
> > Justin Lai <justinlai0215@realtek.com> wrote:
> >   
> > > Andrew Lunn <andrew@lunn.ch> wrote:  
> > > >
> > > > On Mon, Jun 01, 2026 at 02:23:41PM +0800, Justin Lai wrote:  
> > > > > The hardware parser incorrectly interprets 319/320 in a short IP
> > > > > fragmented UDP packet payload as standard PTP destination ports
> > > > > and treats the fragment as a PTP packet for further parsing.  
> > 
> > Is that a packet that has been segmented by IP, or one where the skb is
> > fragmented enough that the data in the header is too short?
> > I thought that IPv4 required an mtu of 128 bytes (ish) and IPv6 somewhat
> > larger - so I don't see how that is a problem.
> > 
> > If the skb is fragmented then you need to move data into the header not pad
> > the frame.
> > 
> > If the hardware really is broken then I suspect you need to disable the feature
> > and suffer the consequences.
> >   
> > > > >
> > > > > If the transport data is smaller than RTASE_MIN_PAD_LEN, the
> > > > > remaining data is insufficient for further parsing and causes hardware TX  
> > hang.  
> > > >
> > > > Where does RTASE_SHORT_PKT_THRESH come into this?
> > > >
> > > > RTASE_MIN_PAD_LEN is 47, so matches all packets which need padding
> > > > up to
> > > > 60 bytes, plus FCS. There are not many such packets, so why both
> > > > this all the complexity and just pad all small packets? Do you have
> > > > any performance numbers which show the complexity is worth it?
> > > >  
> > > > > Pad these packets so the transport data reaches RTASE_MIN_PAD_LEN
> > > > > before transmitting to avoid triggering the hardware issue.
> > > > >
> > > > > Signed-off-by: Justin Lai <justinlai0215@realtek.com>  
> > > >
> > > > Is this a Fix? Please add a Fixes: tag. And base it on net.
> > > >
> > > > https://www.kernel.org/doc/html/latest/process/maintainer-netdev.htm
> > > > l
> > > >
> > > >     Andrew
> > > >
> > > > ---
> > > > pw-bot: cr  
> > >
> > > Hi Andrew,
> > >
> > > RTASE_MIN_PAD_LEN is not the Ethernet minimum-frame padding  
> > threshold.  
> > > It is the minimum transport-data length required by the hardware
> > > parser after the packet is incorrectly detected as a PTP packet.
> > >
> > > Therefore, this workaround needs to pad the packets which can trigger
> > > the hardware issue, rather than just padding packets to the Ethernet
> > > minimum frame size.  
> > 
> > Is that a longer length?
> > Excessive frame padding (beyond 60+FCS) can be treated as a protocol error.
> > 
> > -- David
> >   
> > >
> > > I agree that RTASE_SHORT_PKT_THRESH is not necessary here. I will
> > > remove it in the next revision.
> > >
> > > Yes, this is a fix. I will add a Fixes tag and repost it against the
> > > net tree.
> > >
> > > Thanks,
> > > Justin
> > >  
> 
> Hi David,
>  
> This is an IP fragmented packet, not a fragmented skb.

Ok, your tests are broken for fragmented skb.
skb_tail_pointer() is the end of the initial fragment, not the
end of the actual data.
So you could be adding padding to a full length packet making
it overlong.
Somewhere you need to be looking at skb->len.
Probably with a fast-path check to ignore long packets.

>  
> The issue occurs on a non-initial IP fragment whose payload
> contains values matching the PTP event/general destination
> ports (319/320). The hardware parser incorrectly identifies the
> fragment as a PTP packet and attempts further parsing.

Wait a minute, what stops someone using either of those port numbers
for something else?
There are no hard restrictions on the use of UDP port numbers.
So what does the hardware do with UDP packets to port 319/320 that
are being used for something else entirely?

> The workaround does not modify the IP or UDP length fields. The
> original protocol headers still describe the actual packet size.
>  
> Therefore, the protocol-defined payload size remains unchanged.
>  
> We have tested this workaround and have not observed issues
> caused by the additional padding.

Have you checked all the systems that might receive such packets?

-- David

>  
> Thanks,
> Justin

Re: [PATCH] rtase: Workaround for IP fragmented UDP packet hardware bug

[Alexander Lobakin]

From: Justin Lai <justinlai0215@realtek.com>
Date: Mon, 1 Jun 2026 14:23:41 +0800

> The hardware parser incorrectly interprets 319/320 in a short
> IP fragmented UDP packet payload as standard PTP destination
> ports and treats the fragment as a PTP packet for further
> parsing.
> 
> If the transport data is smaller than RTASE_MIN_PAD_LEN, the
> remaining data is insufficient for further parsing and causes
> hardware TX hang.
> 
> Pad these packets so the transport data reaches
> RTASE_MIN_PAD_LEN before transmitting to avoid triggering the
> hardware issue.
> 
> Signed-off-by: Justin Lai <justinlai0215@realtek.com>

Same 3 things to do that I mentioned in the adjacent thread.

Thanks,
Olek