longjump && re-entrancy

longjump && re-entrancy

Post by William Pu » Thu, 31 Jan 2008 16:11:25

I understand (which is to say I believe it is the case)
that it is safe to call longjump() from a signal handler.
I also understand that non-reentrant functions are unsafe
to call from a signal handler. But it seems to me that
if the program ever calls a non-rentrant function and
longjumps out of a signal handler, then all the issues of
non-reentrancy apply. eg:

fprintf() <-- interrupted
[in handler]:

Could hang if printf still has a lock on the FILE *.

Or does the stack unwinding from longjump magically
release the locks?

longjump && re-entrancy

Post by John Reise » Fri, 01 Feb 2008 01:04:04

longjmp does no "unwinding" at all. It restores the
contents of CPU registers (and state of signal blockage,
if siglongjmp) but does *nothing* else.



longjump && re-entrancy

Post by William Pu » Sat, 02 Feb 2008 04:33:57

So is it in fact unsafe to call longjmp() from a signal
handler if any signal-unsafe function may be
in the stack when the signal is received?

longjump && re-entrancy

Post by David Schw » Sun, 03 Feb 2008 04:32:34

That is one case in which it may be unsafe to use longjmp. The actual
rules are far more complex. For example, 'fprintf' could internally
set a jump point, catch a synchronous signal, and 'longjmp' back from
the signal handler with no safety issue even though 'fprintf' would be
on the stack.

It is unsafe to 'longjmp' out of a singal handler 'behind the back' of
any function that will not normally complete as a result of the jump.

I would warn you that you should exercise extreme caution and ideally
look for some other way. CERT vulnerability 834865 is a great example
of an incredibly-subtle bug caused by using 'longjmp' to exit a signal

CERT secure coding rule SIG32-C prohibits using 'longjmp' in a signal
handler. It is rated high severity (compromise likely to be serious)
and likelihood (likely to create a security problem).


longjump && re-entrancy

Post by Rainer Wei » Mon, 04 Feb 2008 04:55:31

David Schwartz < XXXX@XXXXX.COM > writes:

Actually, fprintf could just copy a variant of the Morris Worm over
the longjmp code in the C-library which would immediatly start
spreading again as soon as someone would use both together. Human
imagination is not usually limited in any way by observable
reality. The products of applying it in this way are called 'fiction'.

longjmp is not defined as being async signal safe, hence, the
behaviour of code executing longjmp from a signal handler is undefined
if the signal happened to interrupt another 'unsafe' function.

Following the simple rule given above is entirely sufficient.

longjump && re-entrancy

Post by Markus Elf » Sat, 01 Mar 2008 00:00:51

> CERT secure coding rule SIG32-C prohibits using 'longjmp' in a signal

Is a bad example implementation shown in the document "siglongjmp()--Perform
Nonlocal Goto with Signal Handling"?

void catcher( int signo ) {
printf( "in catcher() before siglongjmp()\n" );
siglongjmp( mark, -1 );
printf( "in catcher() after siglongjmp() is an error\n" );