Weekly edition	Kernel	Security	Distributions	Contact Us	Search
Archives	Calendar	Subscribe	Write for LWN	LWN.net FAQ	Sponsors

GCC 4.3.0 exposes a kernel bug

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

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