[PATCH 1/6] ip_frag: tolerate duplicate fragments

Stephen Hemminger stephen at networkplumber.org
Tue Jun 30 15:32:48 CEST 2026


On Tue, 30 Jun 2026 08:08:46 +0000
Konstantin Ananyev <konstantin.ananyev at huawei.com> wrote:

> > The reassembly code tracked only a running byte total and reserved slots
> > for the first and last fragments, with no check for a fragment
> > duplicating data already received. A single duplicate could destroy a
> > recoverable datagram:
> >  - a duplicate first or last fragment collided with the reserved slot and
> >    sent the whole entry down the error path, freeing every collected
> >    fragment;
> >  - a duplicate intermediate fragment was appended to a new slot, inflating
> >    frag_size past total_size so reassembly never completed.
> > 
> > RFC 791 reassembly tolerates duplicates: a fragment covering bytes
> > already present carries no new information. Check for an exact duplicate
> > (stored fragment with the same offset and length) and drop only that
> > mbuf, before frag_size is updated, leaving the entry's accounting
> > unchanged.
> > 
> > Overlapping fragments with differing bounds are a separate issue
> > addressed in the next patch.
> > 
> > Fixes: cc8f4d020c0b ("examples/ip_reassembly: initial import")
> > Cc: stable at dpdk.org  
> 
> I am not sure it is a bug and needs to be propagated into the stable releases.
> To me it is more like feature improvement.
> BTW, as this and next patch does change the behavior and probably overall
> performance numbers, - it probably worth to add a line in the release notes.
> As another thought - it might be squashed with next patch in the series
> (ip_frag: discard datagrams with overlapping fragments).
> Apart from that:
> Acked-by: Konstantin Ananyev <konstantin.ananyev at huawei.com>

The problem is that duplicate fragments are used to workaround
firewalls. So latent security issue


More information about the stable mailing list