[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190530123452.GF22536@redhat.com>
Date: Thu, 30 May 2019 14:34:53 +0200
From: Oleg Nesterov <oleg@...hat.com>
To: Jann Horn <jannh@...gle.com>
Cc: "Eric W . Biederman" <ebiederm@...ssion.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Kees Cook <keescook@...omium.org>,
David Howells <dhowells@...hat.com>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] ptrace: restore smp_rmb() in __ptrace_may_access()
On 05/29, Jann Horn wrote:
>
> --- a/kernel/cred.c
> +++ b/kernel/cred.c
> @@ -450,6 +450,15 @@ int commit_creds(struct cred *new)
> if (task->mm)
> set_dumpable(task->mm, suid_dumpable);
> task->pdeath_signal = 0;
> + /*
> + * If a task drops privileges and becomes nondumpable,
> + * the dumpability change must become visible before
> + * the credential change; otherwise, a __ptrace_may_access()
> + * racing with this change may be able to attach to a task it
> + * shouldn't be able to attach to (as if the task had dropped
> + * privileges without becoming nondumpable).
> + * Pairs with a read barrier in __ptrace_may_access().
> + */
> smp_wmb();
Hmm. Now that I tried to actually read this patch I do not understand this wmb().
commit_creds() does rcu_assign_pointer(real_cred) which implies smp_store_release(),
the dumpability change must be visible before ->real_cred is updated without any
additional barriers?
Oleg.
Powered by blists - more mailing lists