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

[Justin Lai <justinlai0215@realtek.com>]

David Laight <david.laight.linux@gmail.com> wrote:
> 
> On Tue, 9 Jun 2026 08:20:10 +0000
> Justin Lai <justinlai0215@realtek.com> wrote:
> 
> > Simon Horman <horms@kernel.org> wrote:
> > >
> > > From: 'Simon Horman' <horms@kernel.org>
> > >
> > > This is an AI-generated review of your patch. The human sending this
> > > email has considered the AI review valid, or at least plausible.
> > > Full review at: https://sashiko.dev
> > > ---
> > > rtase: Workaround for IP fragmented UDP packet hardware bug
> > >
> > > 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. Pad these
> > > packets so the transport data reaches RTASE_MIN_PAD_LEN before
> > > transmitting to avoid triggering the hardware issue.
> > >
> > > > diff --git a/drivers/net/ethernet/realtek/rtase/rtase_main.c
> > > > b/drivers/net/ethernet/realtek/rtase/rtase_main.c
> > > > index ef13109c49cff..b686b84e15fe2 100644
> > > > --- a/drivers/net/ethernet/realtek/rtase/rtase_main.c
> > > > +++ b/drivers/net/ethernet/realtek/rtase/rtase_main.c
> > >
> > > [ ... ]
> > >
> > > > @@ -1247,6 +1248,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;
> > >
> > > [Severity: High]
> > > Does this check fail to traverse IPv6 extension headers?
> > >
> > > If an IPv6 packet contains extension headers, such as an IPv6
> > > fragment (IPPROTO_FRAGMENT), the nexthdr field will contain the
> > > extension header's protocol number instead of UDP.
> > >
> > > Doesn't this bypass the workaround for the exact fragmented packets
> > > it is intended to fix?
> > >
> > Thanks for the review.
> >
> > Unlike IPv4, IPv6 does not require extension header parsing for this
> > workaround. The hardware only treats IPv6 packets without extension
> > headers as PTP packets for further parsing.
> >
> > Therefore, IPv6 packets carrying extension headers, including
> > fragments, do not enter this parsing path and are not affected by the
> > hardware issue addressed by this workaround.
> >
> > Skipping such packets is intentional.
> 
> I thought you said that the problem only arose with packets that are
> fragmented by IPv[46], in particular short final fragments.
> If your hardware checks for extension headers then doesn't that mean that you
> never have a problem with IPv6 packets.
> 
> -- David
> 
Thanks for the review.

To clarify, the issue is not specific to fragmentation.

The hardware performs additional parsing on packets identified as
PTP. The issue is triggered when the packet is shorter than expected,
i.e. UDP header and payload < 47, and the parser attempts to access
data beyond what is present in the packet.

For IPv6, the hardware only enters this parsing path when the IPv6
Next Header field directly indicates UDP. Therefore, packets carrying
IPv6 extension headers never reach the affected parser, so traversing
extension headers is not required for this workaround.

I'll update the commit message in the next version to make this
behavior clearer.

Thanks,
Justin
> ...