IDIV DoS (INT_MIN / -1)(kqueue.org) |
IDIV DoS (INT_MIN / -1)(kqueue.org) |
Assuming x86 signed overflow behavior, you're just back to INT_MIN again? Or am I crazy?
http://www.exploringbinary.com/why-volatile-fixes-the-2-2250...
This guy here over at http://blog.andreas.org/display?id=9 mentions at least: "Android libc, gcc libio, gcc java runtime, newlib libc, GNU Mono, Apple's libc, mozilla"
It was particularly nasty because it could easily be exploited simply by putting that specific decimal number into a web form or whatever, and for each request a thread on the backend server would lock a CPU to 100% usage until sysadmins discover and kill those threads, worst case.
I for one just learned to love doubles...
int main(int argc, char *argv[]) { return (1LL << 63) / atoi(argv[1]); }
Note that this issue has been written about before by Tavis Ormandy: http://my.opera.com/taviso/blog/show.dml/639454Also, what optimization level did you run with?
define i64 @crash() nounwind uwtable readnone optsize {
ret i64 undef
}
In machine code terms, on x86-64 this turns into a function composed entirely of the ret opcode. gcc-4.6 adds an xor eax, eax before the ret.It looks like it was once an interpreter, but is now compiled down to CLR and run with Mono.