linux-kernel - Re: [PATCH 0/2] fix the long standing exec vs kill race

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.LFD.0.9999.0712021218290.8458@woody.linux-foundation.org>
Date:	Sun, 2 Dec 2007 12:26:26 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Oleg Nesterov <oleg@...sign.ru>
cc:	Simon Holm Th?gersen <odie@...aau.dk>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Davide Libenzi <davidel@...ilserver.org>,
	Ingo Molnar <mingo@...e.hu>,
	Roland McGrath <roland@...hat.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/2] fix the long standing exec vs kill race

On Sun, 2 Dec 2007, Oleg Nesterov wrote:
> 
> exec() from the signal handler doesn't do sys_sigreturn(), so we don't unblock
> the signal, and it remains blocked after exec().
> 
> Hmm. Is this linux bug, or application bug?

I think that's an application bug.

The kernel does the obvious (and required) thing: it preserves the 
list of blocked signals over the execve(). And if you call execve() from 
within a signal handler, that list of blocked signals will obviously 
include the signals that got blocked by the execution of the signal 
itself.

(Side note: I also suspect that the program is not strictly POSIX 
conforming, and that execve() isn't in the list of functions that are safe 
to call from a signal handler in the first place, but that's a totally 
separate issue).

So if havign the signal blocked isn't what the application wants, I'd 
suggest one of:
 - just set the signal mask by hand to whatever mask you want (perhaps 
   also marking the signal handler with SIGIGN or SIGDFL or whatever)
 - alternatively, if you control the program being execve'd, just do it in 
   that progam instead.
 - use siglongjmp in the signal handler to get out of the signal handler 
   context and do it that way.
 - use a "sigatomic_t" flag, set it in the signal handler, and then do the 
   execve() in the main loop if it's set.

The last one is the safest one in many ways (since it doesn't care if you 
get a hundred of those signals in close succession - and you could also 
make it a counter or something if you want to actually count those 
things).

		Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/