Page MenuHomeFreeBSD

Small patch to optionally remove the TCP reassembly max queue length
AbandonedPublic

Authored by wma on Jul 22 2021, 10:30 AM.
Tags
None
Referenced Files
Unknown Object (File)
Wed, Apr 17, 10:49 PM
Unknown Object (File)
Dec 20 2023, 6:02 AM
Unknown Object (File)
Nov 10 2023, 4:42 AM
Unknown Object (File)
Nov 8 2023, 4:53 AM
Unknown Object (File)
Oct 17 2023, 3:58 AM
Unknown Object (File)
Oct 7 2023, 3:38 AM
Unknown Object (File)
May 4 2023, 8:21 PM
Unknown Object (File)
Apr 8 2023, 10:44 AM
Subscribers

Details

Reviewers
melifaro
ae
mw
Group Reviewers
transport
Summary

Small patch to optionally remove the TCP reassembly max queue length

Diff Detail

Lint
Lint Skipped
Unit
Tests Skipped

Event Timeline

wma requested review of this revision.Jul 22 2021, 10:30 AM

Can you explain a bit more about the rationale?

One of the reason for the reassembly queue length limit is to prevent DOS attacks by injecting arbitrarily ordered packets, where traversal of the queue can peg the CPU extremely... Only "common" cases, expected to happen in non-pathological situations, are handled efficiently with the tailq (prepend/append) - an attacker could trigger the most complex reassembly path until all of the receive window is exhausted (byte-for-byte).

Why do you need a special handling of 0? Can't the user not just use INT_MAX?

a'x