| Bug ID |
9936
|
| Summary |
epan/follow.c - Incorrect comparing a sequence number of TCP fragment when its value wraps over uint32_t limit
|
| Classification |
Unclassified
|
| Product |
Wireshark
|
| Version |
1.10.5
|
| Hardware |
All
|
| OS |
All
|
| Status |
UNCONFIRMED
|
| Severity |
Major
|
| Priority |
Low
|
| Component |
Dissection engine (libwireshark)
|
| Assignee |
[email protected]
|
| Reporter |
[email protected]
|
Created attachment 12667 [details]
capture file and my patch for git
Build Information:
wireshark 1.10.5 (SVN Rev Unknown from unknown)
Copyright 1998-2013 Gerald Combs <[email protected]> and contributors.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Compiled (64-bit) with GTK+ 2.24.22, with Cairo 1.12.14, with Pango 1.34.1,
with
GLib 2.36.3, with libpcap, with libz 1.2.7, with POSIX capabilities (Linux),
without libnl, with SMI 0.4.8, with c-ares 1.10.0, with Lua 5.1, without
Python,
with GnuTLS 3.1.18, with Gcrypt 1.5.3, with MIT Kerberos, with GeoIP, with
PortAudio V19-devel (built May 4 2013 13:59:07), with AirPcap.
Running on Linux 3.12.11-201.fc19.x86_64, with locale en_US.utf8, with libpcap
version 1.4.0, with libz 1.2.7, GnuTLS 3.1.20, Gcrypt 1.5.3, without AirPcap.
Intel(R) Core(TM) i5-2500 CPU @ 3.30GHz
Built using gcc 4.8.2 20131212 (Red Hat 4.8.2-7).
--
When packet with TCP segment comes to TCP reassembling without ACK, the
reassemble_tcp() function copies it to list of unACKed fragments.
When this fragment has sequence number with wrapped value, less that current
acknowledged sequence number of TCP flow (which is high and near to wrapping) -
this fragment is going to be detected as "latecomer" and discarded.
IMPACT:
All of following packets are going to be detected as "latecomers" and discarded
by the same way, because sequence number of TCP flow isn't updated to wrapped
value correctly.
CAPTURE FILES:
tcp-seq-wraps-in-fragment-12-tiny.pcap.bz2 - this trace demonstrates this
defect during reassembling packet #12.
It is a trace with NFSv3 payload. Some packets with RPC/NFSv3 transmitted data
(and with TCP ACKs) were discarded during the capturing.
HOW TO DUPLICATE:
1. Extract tcp-seq-wraps-in-fragment-12-tiny.pcap from archive.
2. Open tcp-seq-wraps-in-fragment-12-tiny.pcap by Wireshark.
3. In TCP "Protocol Preferences", disable "Relative sequence numbers". Just to
see real sequence numbers
4. Click Analyze -> Follow TCP Stream, and look at reassembled TCP flows.
Blue lines are RPC/NFS responses in 10.6.137.113 to 10.6.137.109 flow.
They are Ok.
Red lines are RPC/NFS calls in 10.6.137.109 to 10.6.137.113 flow.
Data of this flow in truncated on packet #12. Where the TCP segment has wrapped
sequence number.
PATCH:
FIX-tcp-seq-wraps-in-unack-fragment.patch - it is one-line fix.
Just a comparison replacement:
"if( current->seq < seq[idx] ) {"
with wrap-friendly macro:
"if( LT_SEQ(current->seq, seq[idx]) ) {"
After this fix, the condition returns false(correct) and packet is going to
updating sequence number of TCP flow by its wrapped seq number.
Thanks,
Pavel K ([email protected])
You are receiving this mail because:
- You are watching all bug changes.