The most interesting part is the faulty code:
Limit = SpGetUInt32 (Buf);
...
UInt16Ptr = (KpUInt16_t *)SpMalloc (Limit * (KpInt32_t)sizeof (*UInt16Ptr));
...
for (Index = 0; Index < Limit; Index++)
*UInt16Ptr++ = SpGetUInt16 (Buf);
...
Normally, the heap overflow would just terminate the process as the
copy length is kind of wild. However, JDK installs a SEGV handler
which accesses a lot of (potentially trashed) memory in the process of
putting together a meaningful crash dump. It's quite likely that this
makes the condition exploitable as per a previous bug in this area:
http://scary.beasts.org/security/CESA-2006-004.html