What are the dangers of floating point exceptions on invalid entries?

advertisements

I ran some fuzzying on dcraw and found a floating point exception.

What are the dangers of this? It reads some length plen from the corrupted file and computes foo[i % plen]. If plen == 0 then this is undefined by the standard and gcc throws a floating point exception. EDIT: And the exception is not caught (this is C) and the program terminates.

Should I care? Is there any scenario where this could be exploited or cause other bad things? One possible correct behaviour of the code would be to notice that the file is corrupted and just exist. How is that different than throwing a FPE and then exiting?

(I'm surprised that I haven't found a question on this because this seems very basic to me.)


If plen == 0 then this is undefined by the standard ...

Exactly. That means, a compiler is free to assume it doesn't happen. This code, for example

int foo(int m, int n) {
    if(n == 0) return m % n;
    return 0;
}

is compiled to

foo:                                    # @foo
    xorl    %eax, %eax
    ret

by clang -std=c99 -S -O2 on my machine (Intel x86). The if branch is assumed never to be entered and foo returns 0 unconditionally. No FPE, no crash. (I couldn't find a similar small example with gcc, unfortunately.)

... and gcc throws a floating point exception.

Not quite. That's your CPU if code tries to divide by zero. But, as said above, there is no guarantee that such code is generated at all.

I doubt that GCC defines anything here (and couldn't find anything indicating that in the documentation).

Should I care? Is there any scenario where this could be exploited or cause other bad things? One possible correct behaviour of the code would be to notice that the file is corrupted and just exist. How is that different than throwing a FPE and then exiting?

You should care. With some bad luck, your programme could proceed with a wrong input file, see above.

And an error message "Invalid input file." is much nicer in my opinion than just "Floating-pointing exception.". The former tells me (as the end user) what's wrong, the latter only tells me that there is a bug in the software (I would consider it such).