linux-kernel - Re: [BUG] signal: sighand unprotected when accessed by /proc

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: <CA+55aFzT5CGv_T60voAqR+4PfiMmJmsDZLid2DZ4=+X8uvF+ig@mail.gmail.com>
Date:	Tue, 3 Jun 2014 11:03:49 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Oleg Nesterov <oleg@...hat.com>
Cc:	Steven Rostedt <rostedt@...dmis.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Peter Zijlstra <peterz@...radead.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Ingo Molnar <mingo@...nel.org>,
	Clark Williams <williams@...hat.com>
Subject: Re: [BUG] signal: sighand unprotected when accessed by /proc

On Tue, Jun 3, 2014 at 10:26 AM, Oleg Nesterov <oleg@...hat.com> wrote:
>
> looks like, SLAB_DESTROY_BY_RCU logic is broken?

I haven't looked at the code yet, but SLAB_DESTROY_BY_RCU can be
subtle and very dangerous.

The danger is that the *slab* itself is free'd by RCU, but individual
allocations can (and do) get re-used FOR THE SAME OBJECT TYPE without
waiting for RCU!

This is subtle. It means that most people who think that "it's free'd
by RCU" get it wrong. Because individual allocations really aren't at
all RCU-free'd, it's just that the underlying memory is guaranteed to
not change type or be entirely thrown away until after a RCU grace
period.

That means that the only thing you can use rcu-delayed are:
 (a) pure optimistic reads
 (b) idempotent things that are initialized by the constructor, and
_not_ by the allocation.

Nothing else.

An example of (b) is having a lock that is initialized by the
constructor, and that everybody else uses properly: you may have
delayed people locking/unlocking it, but as long as they don't screw
anything else up they won't break even if the data structure was
re-used by a new allocations.

Without looking at the code, it sounds like somebody may doing things
to "sighand->lock->wait_list" that they shouldn't do. We've had cases
like that before, and most of them have been changed to *not* use
SLAB_DESTROY_BY_RCU, and instead make each individual allocation be
RCU-free'd (which is a lot simpler to think about, because then you
don't have the whole re-use issue).

Of course, it could easily be lack of any RCU protection too. As
mentioned, I didn't really check the code. I just wanted to clarify
this subtlety, because while I think Oleg knows about it, maybe others
didn't quite catch that subtlety.

And this could easily be an RT issue, if the RT code does some
re-initialization of the rtmutex that replaces the spinlock we have.

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