linux-kernel - Re: [PATCH v2 1/3] set_dumpable: fix the theoretical race with itself

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] [day] [month] [year] [list]

Message-Id: <20131119142058.92a85a2aa91b61565f787c99@linux-foundation.org>
Date:	Tue, 19 Nov 2013 14:20:58 -0800
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Oleg Nesterov <oleg@...hat.com>
Cc:	Alex Kelly <alex.page.kelly@...il.com>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Josh Triplett <josh@...htriplett.org>,
	Kees Cook <keescook@...omium.org>,
	Petr Matousek <pmatouse@...hat.com>,
	Vasily Kulikov <segoon@...nwall.com>,
	linux-arch@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 1/3] set_dumpable: fix the theoretical race with
 itself

On Tue, 19 Nov 2013 15:43:15 +0100 Oleg Nesterov <oleg@...hat.com> wrote:

> set_dumpable() updates MMF_DUMPABLE_MASK in a non-trivial way to
> ensure that get_dumpable() can't observe the intermediate state,
> but this all can't help if multiple threads call set_dumpable()
> at the same time.
> 
> And in theory commit_creds()->set_dumpable(SUID_DUMP_ROOT) racing
> with sys_prctl()->set_dumpable(SUID_DUMP_DISABLE) can result in
> SUID_DUMP_USER.
> 
> Change this code to update both bits atomically via cmpxchg().
> 
> Note: this assumes that it is safe to mix bitops and cmpxchg. IOW,
> if, say, an architecture implements cmpxchg() using the locking
> (like arch/parisc/lib/bitops.c does), then it should use the same
> locks for set_bit/etc.

I suppose that is reasonable - atomic operations on memory should be
atomic wrt other classes of atomic operations on the same memory.  So
set_bit() has to "know" about concurrent cmpxchg().  It *has* to be
this way to fully emulate the hardware-based RMW operations.

parisc got that right.  I wonder if all other architectures did, and
how on earth we can communicate this to future arch developers..

--
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/