GCC 4.3.0 exposes a kernel bug [LWN.net]

GCC 4.3.0 exposes a kernel bug

Posted Mar 7, 2008 21:44 UTC (Fri) by daney (subscriber, #24551)
Parent article: GCC 4.3.0 exposes a kernel bug

> This has the effect of leaking one bit of state from the user space
> process that was running when the signal occurred to the signal
> handler, which could be in another process.

The last time I checked, signal handlers are not in a different process from the one receiving
the signal.  They are run on one of the threads of the process that received the signal.  The
bug is that the state leaks from that specific thread into the signal handler running on the
same thread.

(Log in to post comments)

GCC 4.3.0 exposes a kernel bug

Posted Mar 7, 2008 21:57 UTC (Fri) by shahms (subscriber, #8877) [Link]

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.

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