| |||||||||||||
GCC 4.3.0 exposes a kernel bugGCC 4.3.0 exposes a kernel bugPosted Mar 7, 2008 21:57 UTC (Fri) by shahms (subscriber, #8877)In reply to: GCC 4.3.0 exposes a kernel bug by daney Parent article: GCC 4.3.0 exposes a kernel bug
There's no requirement that the current executing process be the one that receives the signal. For example: Process 1: kill(proc2, SIGHUP); Process 2: signal_handler() Doing some hand-wavy magic about the scheduler running process 2 immediately when process 1 sends the signal. Process 1 would have been executing and would get interrupted so that process 2's signal handler could process the HUP. If process 1 had changed the DF, it would "leak" into process 2.
(Log in to post comments)
GCC 4.3.0 exposes a kernel bug Posted Mar 7, 2008 22:19 UTC (Fri) by JoeBuck (subscriber, #2330) [Link] We were arguing about this on the gcc list, and it was unclear to me whether the DF flag could actually leak from one process to another (indicating a true security bug, however minor). If a context switch occurs, wouldn't the kernel restore all of process 2's registers before entering the signal handler?Can a kernel expert confirm or deny this? (At least, for currently deployed kernels)?
GCC 4.3.0 exposes a kernel bug Posted Mar 7, 2008 22:20 UTC (Fri) by zlynx (subscriber, #2285) [Link] That scenario requires a context switch, and I believe that the kernel handled that properly.
GCC 4.3.0 exposes a kernel bug Posted Mar 7, 2008 22:23 UTC (Fri) by daney (subscriber, #24551) [Link] The flag bits come from the thread executing the signal handler, not some other place (process).
|
|||||||||||||