Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Ethereal-dev: [Ethereal-dev] Weird bug on MSVC build only (probably HTTP or tvb_get_ptr)

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: Biot Olivier <Olivier.Biot@xxxxxxxxxxx>
Date: Thu, 29 Apr 2004 19:59:23 +0200
Hi list,

I have a (medium-sized) capture that only causes crashes on Win32 builds
(not on cygwin builds) after a certain number of operations on the capture
(like using the "decode as" option to match a given TCP stream to HTTP).
Both builds have an identical source tree (cvs copy from this morning).

Where Ethereal crashes depends on the order and type of operations I perform
on the capture. I however invariably get the following information from a
debug session:
	pinfo->fd->flags = 0
	pinfo->ptype = 2 (TCP)
	pinfo->srcport = 80
	pinfo->match_port = 80
	pinfo->match_string = (null)
	pinfo->bytes_until_next_pdu = 1.869.426.276 (0x6F6D2E64)

I strongly suspect the pinfo->bytes_until_next_pdu value (which is the same
for some crashes, but I've also seen a value of 8) is the reason why I get
the crash. It looks like it is being incorrectly set somewhere (maybe in TCP
reassembly code?). I have all TCP options ticked except for the last (try
heuristic dissectors first), and I have all HTTP and IP options ticked too.

The packets where the error occurs are the last from a TCP reassembly for
reassembling a HTTP response.

If I inspect the last function from the stack, the debugger points at
basic_response_dissector() in packet-http.c at the if statement:

	if (sscanf((const gchar *)data, "%d.%d %d", &minor, &major,
&status_code) == 3) {

If I inspect the value returned from the statement on the line before the if
statement:

	data = tvb_get_ptr(tvb, 5, 12);

then I don't get a 12-byte copy of the data but instead I get a pointer to
the real data (which is much longer than the expected 12 bytes). So it looks
like the sscanf() call reads past the allowed memory? This is somehow
confirmed by the fact that the minor, major and status_code variables are
not initialized.

I also have to say that the reassembled data in the error packets always
consists of very small fragments (sometimes less than 10 bytes).

This is the stack trace of one of such errors:

MSVCRT! 77c3e958()
basic_response_dissector(tvbuff * 0x04344528, _proto_node * 0x02080fc0, int
10) line 790 + 27 bytes
dissect_http_message(tvbuff * 0x04344528, int 0, _packet_info * 0x032ffb08,
_proto_node * 0x02072df0) line 496 + 15 bytes
dissect_http(tvbuff * 0x04344528, _packet_info * 0x032ffb08, _proto_node *
0x02072df0) line 1413 + 21 bytes
call_dissector_through_handle(dissector_handle * 0x0172bfe8, tvbuff *
0x04344528, _packet_info * 0x032ffb08, _proto_node * 0x02072df0) line 363 +
18 bytes
call_dissector_work(dissector_handle * 0x0172bfe8, tvbuff * 0x04344528,
_packet_info * 0x032ffb08, _proto_node * 0x02072df0) line 513 + 21 bytes
dissector_try_port(dissector_table * 0x01773208, unsigned int 80, tvbuff *
0x04344528, _packet_info * 0x032ffb08, _proto_node * 0x02072df0) line 776 +
21 bytes
decode_tcp_ports(tvbuff * 0x043444f4, int 0, _packet_info * 0x032ffb08,
_proto_node * 0x02072df0, int 80, int 41451) line 2362 + 34 bytes
process_tcp_payload(tvbuff * 0x043444f4, volatile int 0, _packet_info *
0x032ffb08, _proto_node * 0x02072df0, _proto_node * 0x022bf198, int 80, int
41451, unsigned int 0, unsigned int 0, int 0) line 2410 + 35 bytes
desegment_tcp(tvbuff * 0x043444c0, _packet_info * 0x032ffb08, int 20,
unsigned int 273, unsigned int 650, unsigned int 80, unsigned int 41451,
_proto_node * 0x02072df0, _proto_node * 0x022bf198) line 1674 + 37 bytes
dissect_tcp_payload(tvbuff * 0x043444c0, _packet_info * 0x032ffb08, int 20,
unsigned int 273, unsigned int 650, unsigned int 80, unsigned int 41451,
_proto_node * 0x02072df0, _proto_node * 0x022bf198) line 2481 + 41 bytes
dissect_tcp(tvbuff * 0x043444c0, _packet_info * 0x032ffb08, _proto_node *
0x02072df0) line 2892 + 69 bytes
call_dissector_through_handle(dissector_handle * 0x017a1988, tvbuff *
0x043444c0, _packet_info * 0x032ffb08, _proto_node * 0x02072df0) line 363 +
18 bytes
call_dissector_work(dissector_handle * 0x017a1988, tvbuff * 0x043444c0,
_packet_info * 0x032ffb08, _proto_node * 0x02072df0) line 513 + 21 bytes
dissector_try_port(dissector_table * 0x0172d168, unsigned int 6, tvbuff *
0x043444c0, _packet_info * 0x032ffb08, _proto_node * 0x02072df0) line 776 +
21 bytes
dissect_ip(tvbuff * 0x04344058, _packet_info * 0x032ffb08, _proto_node *
0x02072df0) line 1098 + 33 bytes
call_dissector_through_handle(dissector_handle * 0x0172d2a0, tvbuff *
0x04344058, _packet_info * 0x032ffb08, _proto_node * 0x02072df0) line 363 +
18 bytes
call_dissector_work(dissector_handle * 0x0172d2a0, tvbuff * 0x04344058,
_packet_info * 0x032ffb08, _proto_node * 0x02072df0) line 513 + 21 bytes
dissector_try_port(dissector_table * 0x016ff3f0, unsigned int 2048, tvbuff *
0x04344058, _packet_info * 0x032ffb08, _proto_node * 0x02072df0) line 776 +
21 bytes
ethertype(unsigned short 2048, tvbuff * 0x04344024, int 14, _packet_info *
0x032ffb08, _proto_node * 0x02072df0, _proto_node * 0x02295440, int 3336,
int 3338, int 0) line 178 + 34 bytes
dissect_eth_common(tvbuff * 0x04344024, _packet_info * 0x032ffb08,
_proto_node * 0x02072df0, int 0) line 293 + 48 bytes
dissect_eth_maybefcs(tvbuff * 0x04344024, _packet_info * 0x032ffb08,
_proto_node * 0x02072df0) line 387 + 26 bytes
call_dissector_through_handle(dissector_handle * 0x01790568, tvbuff *
0x04344024, _packet_info * 0x032ffb08, _proto_node * 0x02072df0) line 363 +
18 bytes
call_dissector_work(dissector_handle * 0x01790568, tvbuff * 0x04344024,
_packet_info * 0x032ffb08, _proto_node * 0x02072df0) line 513 + 21 bytes
dissector_try_port(dissector_table * 0x01709920, unsigned int 1, tvbuff *
0x04344024, _packet_info * 0x032ffb08, _proto_node * 0x02072df0) line 776 +
21 bytes
dissect_frame(tvbuff * 0x04344024, _packet_info * 0x032ffb08, _proto_node *
0x02072df0) line 185 + 34 bytes
call_dissector_through_handle(dissector_handle * 0x017099c8, tvbuff *
0x04344024, _packet_info * 0x032ffb08, _proto_node * 0x02072df0) line 363 +
18 bytes
call_dissector_work(dissector_handle * 0x017099c8, tvbuff * 0x04344024,
_packet_info * 0x032ffb08, _proto_node * 0x02072df0) line 513 + 21 bytes
call_dissector(dissector_handle * 0x017099c8, tvbuff * 0x04344024,
_packet_info * 0x032ffb08, _proto_node * 0x02072df0) line 1614 + 21 bytes
dissect_packet(_epan_dissect_t * 0x032ffb00, wtap_pseudo_header *
0x00ccc428, const unsigned char * 0x00ccc4b8, _frame_data * 0x027a42f0,
_column_info * 0x00cdc4cc) line 311 + 32 bytes
epan_dissect_run(_epan_dissect_t * 0x032ffb00, void * 0x00ccc428, const
unsigned char * 0x00ccc4b8, _frame_data * 0x027a42f0, _column_info *
0x00cdc4cc) line 153 + 25 bytes
add_packet_to_packet_list(_frame_data * 0x027a42f0, _capture_file *
0x00ccc3a0, wtap_pseudo_header * 0x00ccc428, const unsigned char *
0x00ccc4b8, int 1) line 799 + 31 bytes
rescan_packets(_capture_file * 0x00ccc3a0, const char * 0x00c59340, const
char * 0x00c59334, int 1, int 1) line 1209 + 37 bytes
redissect_packets(_capture_file * 0x00ccc3a0) line 1034 + 23 bytes
decode_ok_cb(_GtkWidget * 0x01ffaa90, void * 0x030fcae8) line 802 + 10 bytes

Anyone a clue?

Regards,

Olivier