I was running some valgrind fuzzing and I got a file that produces the
following valgrind trace:
==8013== Invalid read of size 1
==8013== at 0x95F89D0: g_str_hash (ghash.c:1732)
==8013== by 0x95F8058: g_hash_table_lookup (ghash.c:365)
==8013== by 0x65DE56E: call_ber_oid_callback (packet-ber.c:518)
==8013== by 0x65DF2BD: dissect_ber_sequence (packet-ber.c:2285)
==8013== by 0x6DB5A8F: dissect_x509af_AlgorithmIdentifier (x509af.cnf:98)
==8013== by 0x65DF2BD: dissect_ber_sequence (packet-ber.c:2285)
==8013== by 0x6DB5BCF: dissect_x509af_T_signedCertificate (x509af.cnf:159)
==8013== by 0x65DF2BD: dissect_ber_sequence (packet-ber.c:2285)
==8013== by 0x6DB5B8F: dissect_x509af_Certificate (x509af.cnf:175)
==8013== by 0x6B50365: dissect_ssl3_handshake (packet-ssl.c:3131)
==8013== by 0x6B51E8A: dissect_ssl3_record (packet-ssl.c:1791)
==8013== by 0x6B52854: dissect_ssl (packet-ssl.c:909)
==8013== Address 0x12f6a420 is 0 bytes inside a block of size 68 free'd
==8013== at 0x4C2B60C: free (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8013== by 0x64DE30C: emem_free_all (emem.c:1240)
==8013== by 0x64E01BA: epan_dissect_run_with_taps (epan.c:333)
==8013== by 0x4134FD: process_packet (tshark.c:3453)
==8013== by 0x40BAA3: main (tshark.c:3256)
In one sense the problem is easy to trace: the oid resolution code is
returning the resolved string in an ep-allocated buffer, which is then
getting freed and subsequently used. However, I'm having trouble
tracking down exactly where this resolved oid is being persisted
between packets, since the way I've followed the trace makes it look
like the oid resolution and subsequent use are happening in the same
packet, in which case it shouldn't be freed in the middle.
I'm hoping this will be obvious to somebody who actually knows the
BER/OID code. If not I'll file a bugzilla and attach the capture.
Evan