| |||||||||||||
|
| |||||||||||||
Why is this a problem?Why is this a problem?Posted Mar 7, 2008 23:58 UTC (Fri) by vonbrand (subscriber, #4458)In reply to: Why is this a problem? by jake Parent article: GCC 4.3.0 exposes a kernel bug
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.
(Log in to post comments)
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.
|
|
||||||||||||