Why is this a problem?

Posted Mar 7, 2008 22:59 UTC (Fri) by jake (editor, #205)
In reply to: Why is this a problem? by mgb
Parent article: GCC 4.3.0 exposes a kernel bug

> Am I missing something?

This problem has nothing to do with building the kernel.  It is in building user space
applications.  So, installing GCC 4.3.0 or a binary built with it on any Linux (or evidently
BSD) kernel released could trigger the problem.  If it does memory/string operations in signal
handlers anyway.

jake

Why is this a problem?

Posted Mar 7, 2008 23:20 UTC (Fri) by mgb (guest, #3226) [Link]

Thanks Jake.  My bad.  I read "signal handler" and thought "interrupt handler".

Why is this a problem?

Posted Mar 7, 2008 23:58 UTC (Fri) by vonbrand (subscriber, #4458) [Link] (2 responses)

No, it has nothing to do with calling mem<foo> in a signal handler. The point is that said functions may set the DF flag, and before it is reset a signal may come in. The signal handler then could run with the flag set, expecting it to be unset. A few instructions inspect this flag.

Why is this a problem?

Posted Mar 8, 2008 0:27 UTC (Sat) by jake (editor, #205) [Link]

> No, it has nothing to do with calling mem<foo> in a signal handler.

What I was trying to say is that it would be a memmove() or something like it in the signal
handler that would be tripped up by DF being set unexpectedly.

jake

Why is this a problem?

Posted Mar 19, 2008 22:33 UTC (Wed) by klossner (subscriber, #30046) [Link]

> No, it has nothing to do with calling mem<foo> in a signal handler.

Sure it does.  If the signal handler call was compiled with the new GCC, then it will expect
the flag to be clear on entry.  If the flag happens to be set and the signal handler calls
mem<foo>, the copy will go backward.  This can be exploited.