On Sun, Dec 15, 2013 at 2:20 PM, Ed Beroset <bero...@mindspring.com> wrote: > Ed Beroset wrote: >> >> Evan Huus wrote: >>> >>> >>> The part that's confusing me is that somehow >>> actx->external.direct_reference seems to be getting a pointer to this >>> stale ep-allocated buffer, but I can't find anywhere in the call stack >>> that value could be set to such a stale buffer. >> >> >> That would probably be dissect_ber_OBJECT_IDENTIFIER which calls >> dissect_ber_object_identifier_str(), which calls >> dissect_ber_any_oid_str() which calls oid_encoded2string. > > > As a correction, I was looking a little more at your original message with > the trace, and I think that in your case it's more likely to be the call to > dissect_x509af_T_extnId(). It's the line that's created by the DEFAULT_BODY > line in asn1/x509af/x509af.cnf line 90. If you look at the generated code, > you'll see that it creates a call to dissect_ber_object_identifier_str() the > last parameter of which is &actx->external.direct_reference.
Thanks for your suggestions. I did a little more digging and documented my findings in bug 9573. Don't think it will be that easy to fix unfortunately, but at least I understand what's going on now. [1] https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=9573 ___________________________________________________________________________ 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
