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
| ||
|
Date: Sat, 16 Feb 2013 00:38:15 +0000 (GMT) From: "Maciej W. Rozycki" <macro@...ux-mips.org> To: Al Viro <viro@...IV.linux.org.uk> cc: Shentino <shentino@...il.com>, Linus Torvalds <torvalds@...ux-foundation.org>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org> Subject: Re: [RFC] SIGKILL vs. SIGSEGV on late execve() failures On Sat, 16 Feb 2013, Al Viro wrote: > > > + send_sig(SIGSEGV, current, 0); > > > > This might be a stupid miscue on my part, but shouldn't it be > > force_sig instead of send_sig? > > > > I've got this crazy hunch that having SEGV masked might muck something up. > > How would you manage to have it masked at that point? setup_new_exec() > is inevitable after success of flush_old_exec() and it will do > flush_signal_handlers() for us. So just to be completely safe here -- is your proposed change going to affect processes being traced anyhow? E.g. won't GDB see some sort of a limbo state when the child is terminated this way? According to ptrace(2) man page SIGKILL is the only exception to the usual child signal trapping policy. Maciej -- 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/
Powered by blists - more mailing lists