Bug 219991 - [tcp][PATCH] TCP process bogus packets with too large ACK
Summary: [tcp][PATCH] TCP process bogus packets with too large ACK
Status: Closed Feedback Timeout
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 10.3-STABLE
Hardware: Any Any
: --- Affects Many People
Assignee: freebsd-net (Nobody)
URL:
Keywords: patch
Depends on:
Blocks:
 
Reported: 2017-06-14 17:34 UTC by zuborg
Modified: 2021-02-01 18:50 UTC (History)
7 users (show)

See Also:

Attachments
patch sys/netinet/tcp_input.c - check incoming ACK number against snd_max (671 bytes, patch)
2017-06-14 17:34 UTC, zuborg 		no flags Details | Diff
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description zuborg 2017-06-14 17:34:13 UTC 
Created attachment 183483 [details]
patch sys/netinet/tcp_input.c - check incoming ACK number against snd_max

Some DPI send bogus TCP packets with wrong SEQ/ACK numbers.
TCP reply by zero packet with last valid SEQ/ACK - this can cause zero-packet exchange loop (IP of FreeBSD server is 88.208.9.79):

10:44:05.500062 IP 31.166.232.167.45174 > 88.208.9.79.80: Flags [S], seq 870523557, win 65535, options [mss 1460,sackOK,TS val 4441706 ecr 0,nop,wscale 6], length 0
10:44:05.500079 IP 88.208.9.79.80 > 31.166.232.167.45174: Flags [S.], seq 3850309907, ack 870523558, win 8192, options [mss 1460,nop,wscale 6,sackOK,TS val 908986662 ecr 4441706], length 0
10:44:05.576661 IP 31.166.232.167.45174 > 88.208.9.79.80: Flags [.], ack 3850309908, win 1369, options [nop,nop,TS val 4441714 ecr 908986662], length 0
10:44:05.578406 IP 31.166.232.167.45174 > 88.208.9.79.80: Flags [R], seq 2787304243, win 1369, length 0
10:44:05.583003 IP 31.166.232.167.45174 > 88.208.9.79.80: Flags [R.], seq 0, ack 3850312661, win 0, length 0
10:44:05.584581 IP 31.166.232.167.45174 > 88.208.9.79.80: Flags [.], ack 3850311208, win 1414, options [nop,nop,TS val 4441715 ecr 908986662], length 0
10:44:05.584587 IP 88.208.9.79.80 > 31.166.232.167.45174: Flags [.], ack 870523558, win 135, options [nop,nop,TS val 908986746 ecr 4441714], length 0
10:44:05.585403 IP 31.166.232.167.45174 > 88.208.9.79.80: Flags [.], ack 3850312508, win 1460, options [nop,nop,TS val 4441715 ecr 908986662], length 0
10:44:05.585408 IP 88.208.9.79.80 > 31.166.232.167.45174: Flags [.], ack 870523558, win 135, options [nop,nop,TS val 908986747 ecr 4441714], length 0
10:44:05.585412 IP 31.166.232.167.45174 > 88.208.9.79.80: Flags [.], ack 3850312660, win 1500, options [nop,nop,TS val 4441715 ecr 908986662], length 0
10:44:05.585416 IP 88.208.9.79.80 > 31.166.232.167.45174: Flags [.], ack 870523558, win 135, options [nop,nop,TS val 908986747 ecr 4441714], length 0
10:44:05.589039 IP 31.166.232.167.45174 > 88.208.9.79.80: Flags [F.], seq 870524447, ack 3850312660, win 1500, options [nop,nop,TS val 4441715 ecr 908986662], length 0
10:44:05.589066 IP 88.208.9.79.80 > 31.166.232.167.45174: Flags [.], ack 870523558, win 135, options [nop,nop,TS val 908986751 ecr 4441714], length 0
10:44:05.664713 IP 31.166.232.167.45174 > 88.208.9.79.80: Flags [.], ack 3850312660, win 1500, options [nop,nop,TS val 4441723 ecr 908986662], length 0
10:44:05.664735 IP 88.208.9.79.80 > 31.166.232.167.45174: Flags [.], ack 870523558, win 135, options [nop,nop,TS val 908986826 ecr 4441714], length 0
10:44:05.664738 IP 31.166.232.167.45174 > 88.208.9.79.80: Flags [.], ack 3850312660, win 1500, options [nop,nop,TS val 4441723 ecr 908986662], length 0
10:44:05.664743 IP 88.208.9.79.80 > 31.166.232.167.45174: Flags [.], ack 870523558, win 135, options [nop,nop,TS val 908986826 ecr 4441714], length 0


Note that there were no packets with data and remote side send ACKs for 3850312660, while initial ACK is 3850309907.

My proposal is to check incoming ACKs and drop packets which exceed valid value (th->snd_max)
Some packets (RST?) have zero ACK - they don't have to be dropped.

Patch is tested on 10.3.
Comment 1 Michael Tuexen freebsd_committer freebsd_triage 2018-11-18 14:56:08 UTC 
Can you provide a .pcap file? Whether the reaction from the FreeBSD side is OK not not depends on SEG.SEQ of the received ACK segments. Unfortunately, tcpdump doesn't how SEG.SEQ for the ACK segments.

Please note that https://tools.ietf.org/html/rfc793#section-3.9, page 69, specifies the conditions under which a received TCP segment is acceptable. If the received ACK is not acceptable (this depends on SEG.SEQ), an ACK as the one being sent has to be sent.

So seeing the SEG.SEQ of the ACK segments is crucial here.
Comment 2 Michael Tuexen freebsd_committer freebsd_triage 2021-02-01 18:50:50 UTC 
No response in two years and FreeBSD 10 is not supported anymore. Please re-open, if the problem persists.