Hi all,
I know how you just love bug-reports :-)
Anyway, I have just found a problem in the aforementioned file (CVS 1.4
packet_ldap.c). The attached trace file demonstrates the problem quite
well....
This is an LDAP session from an IBM WAS client to a Netscape Suitespot
server.
I had a quick look at the problem, and it appears that one of the ASN1 calls
is failing, which when it returns doesn't set a length field. Alas, that
field is then used, and *boom* we try to allocate about 3Gb of memory. On my
poor machine that will usually fail... :-)
As a side note, the ASN1 call that is failing is a string_decode. Apparently
one of the above products uses a string type that fails in this test here
(from asn1.c::asn1_octect_string_decode())
if (cls != ASN1_UNI || con != ASN1_PRI || tag != ASN1_OTS) {
/* XXX - handle the constructed encoding? */
ret = ASN1_ERR_WRONG_TYPE;
goto done;
}
either that, or the asn routines fail earlier, which cause this test to be
pointing at the wrong point.
The function that is failing is parse_filter() in packet_ldap.c
If you would like any more information or testing done please let me know,
Paul
ps. I am not on the ethereal-dev list, so if you would like to direct a
question to me, please CC: me.
Attachment:
fail.trace.gz
Description: Binary data
