aboutsummaryrefslogtreecommitdiff
path: root/lib/liby/Makefile
diff options
context:
space:
mode:
authorRandall Stewart <rrs@FreeBSD.org>2021-09-23 14:54:23 +0000
committerRandall Stewart <rrs@FreeBSD.org>2021-09-23 14:54:23 +0000
commitfd69939e79a65d0dea766ac05e4d8b7335819ae1 (patch)
tree6e2dfc8f3be9b068b7cdac5f2cb6835bc4efd2e3 /lib/liby/Makefile
parentdbc7ca59451561a179f9852642e13ef024169d84 (diff)
downloadsrc-fd69939e79a65d0dea766ac05e4d8b7335819ae1.tar.gz
src-fd69939e79a65d0dea766ac05e4d8b7335819ae1.zip
tcp: Two bugs in rack one of which can lead to a panic.
In extensive testing in NF we have found two issues inside the rack stack. 1) An incorrect offset is being generated by the fast send path when a fast send is initiated on the end of the socket buffer and before the fast send runs, the sb_compress macro adds data to the trailing socket. This fools the fast send code into thinking the sb offset changed and it miscalculates a "updated offset". It should only do that when the mbuf in question got smaller.. i.e. an ack was processed. This can lead to a panic deref'ing a NULL mbuf if that packet is ever retransmitted. At the best case it leads to invalid data being sent to the client which usually terminates the connection. The fix is to have the proper logic (that is in the rsm fast path) to make sure we only update the offset when the mbuf shrinks. 2) The other issue is more bothersome. The timestamp check in rack needs to use the msec timestamp when comparing the timestamp echo to now. It was using a microsecond timestamp which ends up giving error prone results but causes only small harm in trying to identify which send to use in RTT calculations if its a retransmit. Reviewed by: tuexen Sponsored by: Netflix Inc. Differential Revision: https://reviews.freebsd.org/D32062
Diffstat (limited to 'lib/liby/Makefile')
0 files changed, 0 insertions, 0 deletions