On Tue, 30 Jun 2026 08:08:46 +0000
Konstantin Ananyev <[email protected]> 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: [email protected]
>
> 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 <[email protected]>
The problem is that duplicate fragments are used to workaround
firewalls. So latent security issue
