Seems to be the second case. Code check on master:
In app/req.c:1561 the call
if(!X509_REQ_add1_attr_by_NID(req, nid, chtype,
(unsigned char *)buf, -1)) {
works through crypto/x509/x509_att.c:313
if ((len == -1) && !(attrtype & MBSTRING_FLAG))
{
if (!ASN1_TYPE_set1(ttmp, attrtype, data))
goto err;
}
and eventually ends up in crypto/asn1/asn1_lib.c: 391 with len = -1
if (c == NULL)
str->data=OPENSSL_malloc(len+1);
producing the encountered error messages.
Hth for further evaluation.
Happy Independence Day,
Cheers Lakhsa
On 03/07/2014 23:09, Michael Wojcik wrote:
>> From: owner-openssl-us...@openssl.org [mailto:owner-openssl-
>> us...@openssl.org] On Behalf Of Jakob Bohm
>> Sent: Thursday, 03 July, 2014 12:22
>>
>> On 7/3/2014 5:50 PM, Steven Kinney wrote:
>>> I enter the following command, as instructed by Cisco:
>>>
>>> req -new -config c:\openssl\share\openssl.cnf -newkey rsa:1024 -nodes
>>> -keyout mykey.pem -out myreq.pem
>>>
>>> And I get the following error:
>>>
>>> Please enter the following 'extra' attributes
>>>
>>> to be sent with your certificate request
>>>
>>> A challenge password []:tester
>>>
>>> Error adding attribute
>>>
>>> 7684:error:0D0BA041:asn1 encoding routines:ASN1_STRING_set:malloc
>>> failure:./crypto/asn1/asn1_lib.c:381:
>>> 7684:error:0B08A041:x509 certificate
>>> routines:X509_ATTRIBUTE_set1_data:malloc
>>> failure:./crypto/x509/x509_att.c:317:
>>> problems making Certificate Request
>> I think the important part is "malloc failure", in which case you
>> simply don't have enough free ram to run the command.
> That's extremely unlikely, since OpenSSL shouldn't be trying to allocate very
> much memory there; and the vast majority of, if not all, systems running the
> openssl binary will be virtual-memory systems that require a lot of effort to
> exhaust the available heap space. (Yes, on POSIX systems you have
> setrusage/ulimit, but it'd be extraordinary to have the heap-space limit set
> low enough to bother "openssl req".) And in any event, "free ram" is nearly
> meaningless on a virtual-memory system.
>
> Per the link supplied by Lakhsa in another message, this appears to be a
> known bug with openssl req on Windows - though I wasn't able to find a ticket
> for it in the OpenSSL tracker, so "known" may only be true for small values.
> I admit I've never tried generating a request with a challenge myself.
>
> On modern general-purpose systems, memory allocation failures are most often
> caused by one of the following:
>
> - A bogus request, often due to e.g. integer underflow leading to a request
> for an unreasonable amount of memory.
> - A request for zero bytes when the implementation returns a null pointer for
> such a request. (It's allowed to do this, or to return a valid pointer, per
> ISO 9899-1990 et seq.) Code often checks for a null return from malloc and
> friends and treats it as an error even if it was trying to allocate a
> zero-byte area.
> - Heap corruption.
> - Runaway recursion that actually does eat up the entire available heap.
> - Playing silly buggers with sub-allocators.
>
> In this case, the first two are probably the most likely.
>
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
