There is an out-of-bounds access The vulnerability is in the parsing of .dxf files. Which is a set of new-line separated groupCode and groupValue pairs. Uses this to parse out various entities, the vulnerability is in the parsing of LWPOLYLINE

The usual flow seems to be:

• groupCode 0 and groupValue “LWPOLYLINE” pair is provided to mark the start of a new entity.
• Followed by groupCode 90 and the number of vertices which allocates buffers for the vertices and initalizes values
• Followed by groupCodes 10, 20, 30, and 42 in sequence providing the four vertices of the entity

The problem being that while the code expects the values to be sent in this order, nothing enforces the ordering. So if groupCode 10 is never sent, the vertexIndex will hold the value -1 because that it was the initalized to in groupCode 90

In the remaining groupCodes this index is used for an array access. In 10, 20 and 30 an offset based on the groupCode is added so no out of bounds access occurs, but in groupCode 42 is particularly interesting:

} else if (groupCode==42 && vertexIndex<maxVertices) { 
	vertices[4*vertexIndex + 3] = toReal(groupValue);  
}

The results of the calculation will be a write to vertices[4*-1+3] or vertices[-1]. Which is an 8-byte (its an array of doubles) out of bounds write to the memory immediately preceding the array. This may be exploitable heap meta-data though this would be determined by the application using the library.