Wireshark-bugs: [Wireshark-bugs] [Bug 8956] Buildbot crash output: fuzz-2013-07-20-32544.pcap

Date Prev · Date Next · Thread Prev · Thread Next
Date Index · Thread Index · Other Months · All Mailing Lists
From: bugzilla-daemon@xxxxxxxxxxxxx
Date: Thu, 01 Aug 2013 20:47:13 +0000

changed bug 8956

What Removed Added
CC   [email protected]

Comment # 2 on bug 8956 from 
What's odd is that gdb crashes on frame 35--that's the one with too many items.

If I look at frame 35 in "tshark -nVr" output I get:

~~~
    [Protocols in frame [truncated]:
eth:ip:tcp:vnc:vnc:vnc:vnc:vnc:vnc:vnc:vnc:vnc:vnc:vnc:vnc:vnc:vnc:vnc:vnc:vnc:vnc:vnc:vnc:vnc:vnc:vnc:vnc:vnc:vnc:vnc:vnc:vnc:vnc:vnc:vnc:vnc:vnc:vnc:vnc:vnc:vnc:vnc:vnc:vnc:vnc:vnc:vnc:vnc:vnc:vnc:vnc:vnc:]
~~~

and:

~~~
    Server Message Type: Framebuffer Update (0)
~~~

But if I look at in Wireshark, that frame is marked as a segment of a
reassembled PDU.  Fine, Wireshark is doing 2 passes and is smarter.

But if I disable VNC's "reassemble segments" preference Wireshark just says
"Server Message Type: Unknown (171)".

Weird.


Also, while 100,000 is an arbitrary number of items, I have a hard time
believing that a 1434 byte message could create 100,000 items.  If we take out
the Ethernet (14), IP (20), and TCP (20) headers that would be 72 items per
byte in the message.  Seems unlikely to me...

Oh, but OK, if I print out the frame and the length of the TVB at the beginning
of dissect_vnc() I get:

~~~
** (process:7779): WARNING **: Frame 35, len=1448

** (process:7779): WARNING **: Frame 35, len=1449

** (process:7779): WARNING **: Frame 35, len=1452

[...]

** (process:7779): WARNING **: Frame 35, len=2555

** (process:7779): WARNING **: Frame 35, len=2556

** (process:7779): WARNING **: Dissector bug, protocol VNC, in packet 35: More
than 1000000 items in the tree -- possible infinite loop
~~~

So I guess tshark is doing some desegmentation (in 1-pass mode).  Hmmm...

You are receiving this mail because:
  • You are watching all bug changes.