[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20131116190057.GA22666@redhat.com>
Date: Sat, 16 Nov 2013 20:00:57 +0100
From: Oleg Nesterov <oleg@...hat.com>
To: Kees Cook <keescook@...omium.org>,
Andrew Morton <akpm@...ux-foundation.org>
Cc: "security@...nel.org" <security@...nel.org>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
Vasily Kulikov <segoon@...nwall.com>,
Petr Matousek <pmatouse@...hat.com>,
linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org,
Alex Kelly <alex.page.kelly@...il.com>,
Josh Triplett <josh@...htriplett.org>
Subject: [PATCH 0/3] get/set_dumpable() cleanups and theoretical fix
On 11/15, Kees Cook wrote:
>
> On Fri, Nov 15, 2013 at 12:36 PM, Oleg Nesterov <oleg@...hat.com> wrote:
> >
> > unless I missed something, this is the fix, not cleanup ?
> >
> > If commit_creds()->set_dumpable(SUID_DUMP_ROOT) races with
> > sys_prctl()->set_dumpable(SUID_DUMP_DISABLE), we can get
> > SUID_DUMP_USER afaics.
> >
> > Yes, yes, even if I am right this race is very unlikely.
>
> Hm, yes, that is a fix then. I struggle to imagine it being
> exploitable (i.e. control over both threads, one at least already with
> a different cred, etc), but it certainly does look like a bug.
Yes, yes, sure, this is only theoretical.
OK, I am sending the patches to lkml. I didn't dare to keep your ack,
please review v2 (v1 confused bit-mask with bit-number, and in theory
we need ACCESS_ONCE).
It would be really nice if someone can ack the "it is safe to mix
bitops and cmpxchg" assumption mentioned in the changelog.
Alex, Josh, this also partly reverts 179899fd5dc780fe "coredump:
update coredump-related headers", I think fs/coredump.h buys nothing.
Oleg.
fs/coredump.c | 1 -
fs/coredump.h | 6 -----
fs/exec.c | 61 +++++--------------------------------------------
include/linux/sched.h | 25 ++++++++++++++-----
4 files changed, 24 insertions(+), 69 deletions(-)
--
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