> 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.
>
> /Bruce
>
> > first_seg->port = rxq->port_id;
> > @@ -1884,6 +1892,14 @@ iavf_recv_scattered_pkts(void *rx_queue, struct
> rte_mbuf **rx_pkts,
> > } else
> > 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;
> > }
> >
> > first_seg->port = rxq->port_id;
> > --
> > 2.43.0
> >
