linux-kernel - Re: [RFC] SIGKILL vs. SIGSEGV on late execve() failures

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CAGDaZ_oSzQOLsoeWQFNQ8R5-NBKPAUygvjvzvef9q40WBu1sWw@mail.gmail.com>
Date:	Fri, 15 Feb 2013 23:20:18 -0800
From:	Raymond Jennings <shentino@...il.com>
To:	Al Viro <viro@...iv.linux.org.uk>
Cc:	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 Fri, Feb 15, 2013 at 6:20 PM, Al Viro <viro@...iv.linux.org.uk> wrote:
> Arrgh...  OK, I'm a blind idiot.  These places in binfmt_elf.c currently use
> force_sig(), not send_sig_info().  Currently == since 2006 when somebody
> noticed the problem.  Their counterparts in binfmt_elf_fdpic.c were *not*
> noticed.  Anyway, that definitely means we want to do it in a single commit;
> the only remaining question is whether we have any problems with somebody
> ptracing such execve() and then poking the sucker with ptrace();

Personally if I was ptracing another process, I'd be flummoxed if I
saw it get nailed with a fatal segfault that I somehow wasn't allowed
to intercept.

An even bigger question might be why an execve is allowed to get into
an unrecoverable state to begin with.  Assuming that one builds the
new mm_struct and whatnot BEFORE discarding old state, why would
execve be in a position for a fatal error in the first place?

> that _can_
> happen with the current mainline for ELF binaries, so this is not something
> new.  I'm low on coffee and about to crash, so I might be missing some
> horrible problem with it, but in this case I'm fairly sure that such a problem
> would be present in current mainline.
--
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/