ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
April 17th, 2024 | 14:30-16:00 SGT (UTC+8) | Online

Wireshark-dev: Re: [Wireshark-dev] OID/BER memory oddness

From: Evan Huus <eapache@xxxxxxxxx>
Date: Tue, 17 Dec 2013 14:37:02 -0500
On Sun, Dec 15, 2013 at 2:20 PM, Ed Beroset <beroset@xxxxxxxxxxxxxx> 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