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

Wireshark-bugs: [Wireshark-bugs] [Bug 8409] APPCRASH in libglib-2.0-0.dll

Date: Fri, 01 Mar 2013 01:51:34 +0000

changed bug 8409

What Removed Added
Attachment #10139 Flags review_for_checkin? review_for_checkin-

Comment # 6 on bug 8409 from
Comment on attachment 10139 [details]
Address ntsmllp conversation memory issues

I'm afraid valgrind is still complaining with this patch applied. It now says:

==10331== Invalid read of size 8
==10331==    at 0x6834D75: dissect_ntlmssp (string3.h:51)
==10331==    by 0x6381C27: call_dissector_through_handle (packet.c:455)
==10331==    by 0x638244C: call_dissector_work (packet.c:546)
==10331==    by 0x63841C0: call_dissector_with_data (packet.c:2070)
==10331==    by 0x6BF42CC: dissect_spnego_T_responseToken (spnego.cnf:206)
==10331==    by 0x6480FE6: dissect_ber_sequence (packet-ber.c:2221)
==10331==    by 0x6BF3EEF: dissect_spnego_NegTokenTarg (spnego.cnf:252)
==10331==    by 0x647B4EB: dissect_ber_choice (packet-ber.c:3398)
==10331==    by 0x6BF5B55: dissect_spnego (spnego.cnf:273)
==10331==    by 0x6381C27: call_dissector_through_handle (packet.c:455)
==10331==    by 0x638244C: call_dissector_work (packet.c:546)
==10331==    by 0x63841C0: call_dissector_with_data (packet.c:2070)
==10331==  Address 0xf11b300 is 0 bytes inside a block of size 1 alloc'd
==10331==    at 0x4C2CD7B: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==10331==    by 0x9278CD0: g_malloc (gmem.c:159)
==10331==    by 0x63756D5: emem_alloc_glib (emem.c:862)
==10331==    by 0x6375AAD: emem_alloc (emem.c:877)
==10331==    by 0x6833D04: dissect_ntlmssp_blob (packet-ntlmssp.c:966)
==10331==    by 0x6834509: dissect_ntlmssp (packet-ntlmssp.c:1706)
==10331==    by 0x6381C27: call_dissector_through_handle (packet.c:455)
==10331==    by 0x638244C: call_dissector_work (packet.c:546)
==10331==    by 0x63841C0: call_dissector_with_data (packet.c:2070)
==10331==    by 0x6BF42CC: dissect_spnego_T_responseToken (spnego.cnf:206)
==10331==    by 0x6480FE6: dissect_ber_sequence (packet-ber.c:2221)
==10331==    by 0x6BF3EEF: dissect_spnego_NegTokenTarg (spnego.cnf:252)

instead of the old error (the get_unicode_or_ascii_string complaints are
unchanged, of course).

Tangentially, while we're playing around with memsets and buffers, CppCheck
points out that there are several rather trivially optimizable cases earlier in
the dissector. Not strictly related to the bug, but probably worth doing while
we're "in the neighbourhood" as it were:
epan/dissectors/packet-ntlmssp.c:363: performance: Buffer 'pw21' is being
written before its old content has been used.
epan/dissectors/packet-ntlmssp.c:387: performance: Buffer 'pw21' is being
written before its old content has been used.
epan/dissectors/packet-ntlmssp.c:430: performance: Buffer 'basekey' is being
written before its old content has been used.
epan/dissectors/packet-ntlmssp.c:431: performance: Buffer 'basekey' is being
written before its old content has been used.
epan/dissectors/packet-ntlmssp.c:577: performance: Buffer 'buf' is being
written before its old content has been used.
epan/dissectors/packet-ntlmssp.c:584: performance: Buffer 'buf' is being
written before its old content has been used.
epan/dissectors/packet-ntlmssp.c:592: performance: Buffer 'buf' is being
written before its old content has been used.
epan/dissectors/packet-ntlmssp.c:791: performance: Buffer 'clientsealkey' is
being written before its old content has been used.


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