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 ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
