Created attachment 132064 [details]
Proof of concept

There is a division by 0 that leads to a SIGFPE.

The vulnerability is in the Function.cc:1626 in the PostScriptFunction::exec function below.

1623          case psOpIdiv:
1624            i2 = stack->popInt();
1625            i1 = stack->popInt();
1626            stack->pushInt(i1 / i2);

popInt() is called twice and the value is stored in i2 and i1. In both cases a 0 is returned causing i1/i2 to SIGFPE. PopInt is seen below. The 0 is returned because the if condition does not satisfy. checkType returns 0.

int popInt()
  {
    if (checkUnderflow() && checkType(psInt, psInt)) {
      return stack[sp++].intg;
    }
    return 0;
  }

CheckType validates that the object being popped is the same type as the function requests (popInt). This check is failed because the type at the stack[sp] is psReal.

GBool checkType(PSObjectType t1, PSObjectType t2)
  {
    if (stack[sp].type != t1 && stack[sp].type != t2) {
      error(-1, "Type mismatch in PostScript function");
      return gFalse;
    }
    return gTrue;
  }
  PSObject stack[psStackSize];
  int sp;
};

The solution could be to check for i2 != 0 before doing the division.

PoC attached.

This vulnerability has been found by Offensive Research at Salesforce.com:
Alberto Garcia (@algillera), Francisco Oca (@francisco_oca) & Suleman Ali (@Salbei_)