#2746 Abort when parsing an istance's PROPERTY.ARRAY with ARRAYSIZE attribute

[Zoltan Micskei]

A bug in parsing a PROPERTY.ARRAY causes an abort in processing an enumeration request.

The environment where the bug was triggered:

• Fedora 21 Server Minimal x86
• sblim-sfcc.i686 2.2.7-3.fc21; openwsman-server.i686 2.4.6-3.fc21; openpegasus as CIMOM, openlmi as providers
• openwsman connecting to the local CIMOM with CIM-XML via sblim-sfcc
• enumerating CIM_Processor with wsmancli
• openpegasus processed the request, returned an instance of LMI_Processor
• when processing the XML request, sfcc aborted, causing a core dump in openwsman

The result is the same if using version 2.2.8 of sfcc built from source.

The stack trace of the fault is the following:

#0  0xb79b3ae3 in vfprintf () from /lib/libc.so.6
#1  0xb7a772d1 in __printf_chk () from /lib/libc.so.6
#2  0xb5775ae1 in str2CMPIValue () from /lib/libcimcClientXML.so.0
#3  0xb577fef7 in setInstProperties () from /lib/libcimcClientXML.so.0
#4  0xb577ef23 in startParsing () from /lib/libcimcClientXML.so.0
#5  0xb57845c7 in scanCimXmlResponse () from /lib/libcimcClientXML.so.0
#6  0xb5779061 in enumInstances () from /lib/libcimcClientXML.so.0
...

The problem is when setting an array property of an instance, it was triggered by this xml fragment:

<PROPERTY.ARRAY NAME="OperationalStatus" TYPE="uint16" PROPAGATED="true" ARRAYSIZE="1">
 <VALUE.ARRAY>
  <VALUE>0</VALUE>
 </VALUE.ARRAY>
</PROPERTY.ARRAY>

The abort is caused because the XtokProperty representing OperationalStatus was parsed into this structure:

$41 = {{value = {data = {{value = 0x10 <error: Cannot access memory at address 0x10>, inst = 0x10}, type = typeValue_Instance}, type = 3042994584},
    ref = {data = {{instancePath = {path = {host = {host = 0x10 <error: Cannot access memory at address 0x10>}, nameSpacePath = {
                value = 0x1 <error: Cannot access memory at address 0x1>}}, instanceName = {className = 0xb5606998 "E\272j\265@", bindings = {
                last = 0x0, first = 0x0}}, type = 0}, localInstancePath = {path = {value = 0x10 <error: Cannot access memory at address 0x10>},
            instanceName = {className = 0x1 <error: Cannot access memory at address 0x1>, bindings = {last = 0xb5606998, first = 0x0}}, type = 0},
          instanceName = {className = 0x10 <error: Cannot access memory at address 0x10>, bindings = {last = 0x1, first = 0xb5606998}}},
        type = typeValRef_Unknown}, type = typeValRef_Unknown, op = 0x0}, array = {max = 16, next = 1, values = 0xb5606998}}, qualifiers = {
    last = 0x0, first = 0xb56aba1a}, null = 0}

Notice, that qualifiers.first is not null, although the property does not have a qualifier.

This triggers in parserUtil.c:143 calling str2CMPIValue() inside setInstProperties(), where in the switch(type) the default branch is executed (as qualifiers.first points to some random memory), where the abort is called.

The root cause is in procPropertyArray() of cimXmlParser.c

The xtokProperty structure gets zeroed in line 971, and after that qualifiers are not touched, but:

         lvalp->xtokProperty.classOrigin = attr[2].attr;
         if (attr[3].attr)
            lvalp->xtokProperty.propagated = !strcasecmp(attr[3].attr, "true");
         lvalp->xtokParam.arraySize = attr[4].attr;
         lvalp->xtokProperty.propType = typeProperty_Array;
         lvalp->xtokProperty.val.array.next = lvalp->xtokProperty.val.array.max = 0;

Line 979 sets lvalp->xtokParam, but lvalp is currently an xtokProperty structure, thus the xtokProperty structure gets corrupted.

If commenting out that line, the enumerate request is processed successfully.

Suggestion: Storing ARRAYSIZE in xtokParam is wrong, but I'm not sure where should it be store (or whether it should be even stored in the first place).

As far as I see from the code the array is initialized in procValueArray() with 16 elements, but it is dynamically extended in valueArray() of grammar.c.

Furthermore, version 2.4.0 of DSP0201 "Representation of CIM in XML" says

1102 On a PROPERTY.ARRAY element within a containing INSTANCE element, the ARRAYSIZE attribute should be absent, and the presence or absence of the ARRAYSIZE attribute shall not be interpreted as meaning that the property type is a fixed-length or variable-length array (that is, the CLASS definition is always authoritative in this respect).

Thus at an instance level it should not be honored, but maybe it could be processed on a class to have a fixed maximal length. But if sfcc uses variable-length arrays always, then ARRAYSIZE would not be used later.

Hope this helps,
Zoltan

[Dave Heller]

Hi Zoltan,

Thanks for the bug report and your thorough investigation. While I could not reproduce the crash (which could be due to my testing on 64bit vs. your 32bit, or it could just be due to my using a very simple example of a property array in my testing), I do agree with your analysis, both on the SFCC code and the CMPI standard.

On the code: yes, it looks like this is not really proper use of "xtokParam" here. The structure being populated here is "xtokPropery" and it's really not safe to access both in the same union like this. I don't know what the original intent was but it was quite possibly a mistake. As you can see, this value (arraySize) is never really consumed in parserUtil.c, so this is basically dead code anyway

And as you pointed out, it is quite unnecessary to store this here regardless. So I'm just going to remove the offending line from the code.

[Dave Heller]

Commit [514a76] for SFCC 2.2.9