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

[Jaromír Doleček]

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.

Jaromir

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Maxime Villard]

Post by Jaromír Doleček
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/
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.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de