Re: TCP reassembly CPU hog - does it need to be fixed? (FreeBSD CVE-2018-6922)

[Maxime Villard <max%m00nbsd.net@localhost>]

Le 09/08/2018 à 20:27, Jaromír Doleček a écrit :
> Hi,
>
> is this problem something we'd need to address in our code too?
>
> https://www.theregister.co.uk/2018/08/08/freebsd_tcp_queue_vulnerability/
>
> FreeBSD advisory:
> https://www.freebsd.org/security/advisories/FreeBSD-SA-18:08.tcp.asc
>
> Brief look on our code reveals we use a queue too, seemingly without
> apparent limits besides available memory.
>
> FreeBSD fix was simply limit the queue to 100 packets by default.

I saw the advisory, but I didn't really understand what's the big deal.
That fragmentation/segmentation can cause issues when too many fragments
arrive, is a well-known problem.

As far as NetBSD is concerned:

	"This causes the CPU time spent on segment processing to grow
	 linearly with the number of segments in the reassembly queue"

On NetBSD it's not completely true, because our TCP reassembly is different
than that of FreeBSD (and OpenBSD).

In NetBSD we merge segments as soon as they are nearby, and keep only one
queue entry for the result of the merging. Therefore the CPU time doesn't
grow linearly with the number of segments.