spine-sdl.zip

107kB

Hello Spine team!

We use the spine-cpp 4.2 runtime in a custom engine, and have recently encountered a crash with a spine that uses a ClippingAttachment.

The problem happens on this line:
EsotericSoftware/spine-runtimesblob/59bcffcf42654465903638811e18c51c87a5c240/spine-cpp/spine-cpp/src/spine/SkeletonClipping.cpp#L127

The new Vector size computed by clippedTriangles.setSize(s + 3 * (clipOutputCount - 2), 0); is negative. Since setSize expects a size_t, which is unsigned, this results in a realloc of 4 GBs or more and it breaks.
The culprit may be the SkeletonClipping::clip() method called before that, that only returns 1 vertex / 2 floats.

I linked a zip with an edited spine-sdl sample that generates this crash. (it contains the .spine + its export + relevant code to setup the tracks)

Runtime information

Spine-cpp runtime 4.2 at this commit: EsotericSoftware/spine-runtimese9cd51e

Some notes

Happens at least on iOS, Android and Mac M1+.
The spine only crashes with very specific track timings, skeleton position and even the texture export scale matters.
Bone::setYDown() also matters, I disabled it in the sample.
We don't see any issue when replacing the code in SkeletonClipping.cpp by the version before this commit EsotericSoftware/spine-runtimesf997a5f
The buggy realloc does not happen with C runtime. The _setSize() function expects an int there so the array will already have more than a negative capacity. The following computations may still be wrong though.
There is an assert assert(newSize >= 0); in Vector::setSize(). This will never detects anything because newSize is unsigned.

Thanks for the help!