On Mon, Jun 15, 2026 at 10:33:15AM +0100, Bruce Richardson wrote:
> On Mon, Jun 15, 2026 at 10:17:41AM +0100, Loftus, Ciara wrote:
> > > Subject: Re: [PATCH] net/iavf: fix scalar Rx path zero-length segment
> > >
> > > On Fri, Jun 12, 2026 at 02:35:31PM +0000, Ciara Loftus wrote:
> > > > When hardware CRC stripping is active, a frame whose on-wire size is an
> > > > exact multiple of the Rx buffer size can cause the NIC to fill the final
> > > > data descriptor and place the four CRC bytes into a separate trailing
> > > > descriptor. After hardware stripping, that descriptor carries zero bytes
> > > > of payload.
> > > >
> > > > The existing CRC cleanup code only handles a zero-length trailing
> > > > segment
> > > > when software CRC stripping is enabled. When hardware stripping is
> > > > active, the zero-length mbuf is silently chained to the reassembled
> > > > packet. Forwarding such a packet causes a zero-length Tx descriptor,
> > > > triggering a Malicious Driver Detection event on the PF and resetting
> > > > the VF.
> > > >
> > > > Fix by adding logic to detect a zero-length final segment when hardware
> > > > CRC stripping is active, and freeing it.
> > > >
> > > > Fixes: a2b29a7733ef ("net/avf: enable basic Rx Tx")
> > > > Fixes: b8b4c54ef9b0 ("net/iavf: support flexible Rx descriptor in normal
> > > path")
> > > > Cc: [email protected]
> > > >
> > > > Signed-off-by: Declan Doherty <[email protected]>
> > > > Signed-off-by: Ciara Loftus <[email protected]>
> > > > ---
> > > > drivers/net/intel/iavf/iavf_rxtx.c | 16 ++++++++++++++++
> > > > 1 file changed, 16 insertions(+)
> > > >
> > > > diff --git a/drivers/net/intel/iavf/iavf_rxtx.c
> > > b/drivers/net/intel/iavf/iavf_rxtx.c
> > > > index a57af7faed..86ebb2618d 100644
> > > > --- a/drivers/net/intel/iavf/iavf_rxtx.c
> > > > +++ b/drivers/net/intel/iavf/iavf_rxtx.c
> > > > @@ -1716,6 +1716,14 @@ iavf_recv_scattered_pkts_flex_rxd(void
> > > *rx_queue, struct rte_mbuf **rx_pkts,
> > > > rxm->data_len =
> > > > (uint16_t)(rx_packet_len -
> > > >
> > > RTE_ETHER_CRC_LEN);
> > > > }
> > > > + } else if (unlikely(rx_packet_len == 0)) {
> > > > + /*
> > > > + * NIC split CRC bytes into a trailing segment
> > > > which is
> > > > + * now empty after hardware CRC stripping. Free
> > > > it.
> > > > + */
> > > > + rte_pktmbuf_free_seg(rxm);
> > > > + first_seg->nb_segs--;
> > > > + last_seg->next = NULL;
> > > > }
> > > >
> > >
> > > The vector paths also handle scattered packets (via reassembly). Do they
> > > need a fix for this? What about the other drivers that work on the PF,
> > > such
> > > as ice/i40e?
> >
> > The vector paths use the common ci_rx_reassemble_packets which already
> > handles the zero-length trailing segment case correctly. When
> > crc_len == 0 and the last segment has data_len == 0, the empty segment
> > is freed.
> >
> > The ice scalar path had the same issue but it was patched in 2022:
> > https://git.dpdk.org/dpdk/commit/?id=90ba4442058a14763e57ca96d03ab1e6044e3e5c
> > I cannot reproduce the behaviour on i40e hardware (either PF or VF) so I
> > don't think it needs to be patched as the HW seems to behave
> > differently.
> >
>
> Thanks for clarifying.
>
> Acked-by: Bruce Richardson <[email protected]>
>
Applied to dpdk-next-net-intel.
thanks,
/Bruce
