浮点异常对无效输入有什么危险？

Question

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.)

Answer 1

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).

Answer 2

Exceptions are thrown to enable you to restore the system to a well defined state after unexpected things happened.

A thrown exceptions does not restore the system to a well defined state. That's your responsibility. Any exploitation happens on the basis of how you do that, not on the basis of the thrown exception itself.

Answer 3

Regarding "Is there any scenario where this could be exploited or 
cause other bad things? "

Recovering from exception entirely depends on the context in which exception was thrown. If exception was thrown by some calculations, the result of which is needed to move forward then it's better to halt the system.

However if your exception is thrown for something which can be ignored OR for which other default options could be provided then you could surely move on from that.

For eg:-

Let's say I am reading .ini using boost program options. On account of some missing variables in .ini file there was some exception. in this case I can recover from exception by providing some suitable default value to that variable.