linux-kernel - Re: [PATCH v2 1/8] exec: Correct comments about "point of no return"

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: <87van0r86d.fsf@xmission.com>
Date:   Mon, 10 Jul 2017 03:46:18 -0500
From:   ebiederm@...ssion.com (Eric W. Biederman)
To:     Kees Cook <keescook@...omium.org>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Andy Lutomirski <luto@...nel.org>,
        David Howells <dhowells@...hat.com>,
        Serge Hallyn <serge@...lyn.com>,
        John Johansen <john.johansen@...onical.com>,
        Casey Schaufler <casey@...aufler-ca.com>,
        Alexander Viro <viro@...iv.linux.org.uk>,
        Michal Hocko <mhocko@...nel.org>,
        Ben Hutchings <ben@...adent.org.uk>,
        Hugh Dickins <hughd@...gle.com>,
        Oleg Nesterov <oleg@...hat.com>,
        "Jason A. Donenfeld" <Jason@...c4.com>,
        Rik van Riel <riel@...hat.com>,
        James Morris <james.l.morris@...cle.com>,
        Greg Ungerer <gerg@...ux-m68k.org>,
        Ingo Molnar <mingo@...nel.org>,
        Nicolas Pitre <nicolas.pitre@...aro.org>,
        Stephen Smalley <sds@...ho.nsa.gov>,
        Paul Moore <paul@...l-moore.com>,
        Vivek Goyal <vgoyal@...hat.com>,
        Mickaël Salaün <mic@...ikod.net>,
        Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
        linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-security-module@...r.kernel.org, selinux@...ho.nsa.gov
Subject: Re: [PATCH v2 1/8] exec: Correct comments about "point of no return"


But you miss it.

The "point of no return" is the call to de_thread.  Or aguably anything in
flush_old_exec.  Once anything in the current task is modified you can't
return an error.

It very much does not have anything to do with brpm.    It has
everything to do with current.


> diff --git a/fs/exec.c b/fs/exec.c
> index 904199086490..7842ae661e34 100644
> --- a/fs/exec.c
> +++ b/fs/exec.c
> @@ -1285,7 +1285,14 @@ int flush_old_exec(struct linux_binprm * bprm)
>  	if (retval)
>  		goto out;
>  
> -	bprm->mm = NULL;		/* We're using it now */
> +	/*
> +	 * After clearing bprm->mm (to mark that current is using the
> +	 * prepared mm now), we are at the point of no return. If
> +	 * anything from here on returns an error, the check in
> +	 * search_binary_handler() will kill current (since the mm has
> +	 * been replaced).
> +	 */
> +	bprm->mm = NULL;
>  
>  	set_fs(USER_DS);
>  	current->flags &= ~(PF_RANDOMIZE | PF_FORKNOEXEC | PF_KTHREAD |

Eric