Page MenuHomeFreeBSD

tcp: TCP_LRO getting bad checksums and sending it in to TCP incorrectly.
ClosedPublic

Authored by rrs on Jul 12 2021, 6:58 PM.
Tags
None
Referenced Files
Unknown Object (File)
Fri, Mar 29, 12:29 PM
Unknown Object (File)
Feb 24 2024, 4:37 AM
Unknown Object (File)
Feb 24 2024, 4:37 AM
Unknown Object (File)
Feb 10 2024, 10:15 AM
Unknown Object (File)
Dec 31 2023, 7:51 PM
Unknown Object (File)
Dec 15 2023, 7:47 AM
Unknown Object (File)
Dec 10 2023, 8:32 PM
Unknown Object (File)
Oct 1 2023, 5:11 AM
Subscribers

Details

Summary

In reviewing tcp_lro.c we have a possibility that some drives may send a mbuf into
LRO without making sure that the checksum passes. Some drivers actually are
aware of this and do not call lro when the csum failed, others do not do this and
thus could end up sending data up that we think has a checksum passing when
it does not.

This change will fix that situation by properly verifying that the mbuf
has the correct markings (CSUM VALID bits as well as csum in mbuf header
is set to 0xffff).

Test Plan

Validate that our new counters are working properly and
we have see that we are properly rejecting mbufs with
bad csums.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

rrs requested review of this revision.Jul 12 2021, 6:58 PM

Opps forgot the tcp_subr.c and tcp_var.h changes too

sys/netinet/tcp_lro.c
133

Would it be better to say Number of packets instead of Number of mbufs?

sys/netinet/tcp_lro.c
1906

Maybe you should keep the predict false.

sys/netinet/tcp_lro.c
133

Good point it is actually packets since its a pkt-hdr we are looking at.

1906

Good idea.

Update with Hans and Michael's suggestions.

This revision is now accepted and ready to land.Jul 13 2021, 12:17 PM