From: Al Viro <viro@ZenIV.linux.org.uk>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Vasily Kulikov <segoon@openwall.com>,
Containers <containers@lists.linux-foundation.org>,
Serge Hallyn <serge.hallyn@canonical.com>,
"Serge E. Hallyn" <serge.hallyn@ubuntu.com>,
linux-kernel@vger.kernel.org,
kernel-hardening@lists.openwall.com
Subject: [kernel-hardening] Re: [PATCH/RFC] user_ns: fix missing limiting of user_ns counts
Date: Sat, 29 Dec 2012 05:13:44 +0000 [thread overview]
Message-ID: <20121229051344.GC4939@ZenIV.linux.org.uk> (raw)
In-Reply-To: <87wqw15wqb.fsf@xmission.com>
On Fri, Dec 28, 2012 at 08:05:32PM -0800, Eric W. Biederman wrote:
> Yes. Gcc can't turn a tail call into a jump in even the most basic
> cases apparently.
What. The. Fuck?
You have introduced unlimited recursion on kernel stack. OK, it's
unpleasant, but it can happen to anybody. But then you have the gall
to complain about gcc optimizations not saving your broken code. Are
you serious?
It's not a question of gcc being not smart enough, and while we are
at it, it's *not* a basic case at all - we have recursion going through
the callback and we have non-trivial return value on top of that; if
the caller of kref_put() had checked said return value, you would've
been unable to turn that into a loop at all.
Are you seriously saying that you relied on compiler being smart enough
to
* notice that return value of kref_put() is ignored
* notice that therefore the return value of kref_sub() is ignored
* notice that you have this call of put_user_ns() calling
kref_put() calling kref_sub() inside the callback we'd passed through the
last two levels of calls and that we are dealing with the tail recursion
here
... so that your code wouldn't have stepped into unlimited recursion?
I sincerely hope that you are not that much of an idiot. If nothing else,
even if gcc did spot that one, the result would've been extremely brittle -
minor change to kref.h several year down the road and we'd get the problem.
next prev parent reply other threads:[~2012-12-29 5:13 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-28 17:56 [kernel-hardening] [PATCH/RFC] user_ns: fix missing limiting of user_ns counts Vasily Kulikov
2012-12-28 18:43 ` [kernel-hardening] " Al Viro
2012-12-28 19:04 ` Vasily Kulikov
2012-12-28 19:21 ` Al Viro
2012-12-29 4:05 ` Eric W. Biederman
2012-12-29 5:13 ` Al Viro [this message]
2012-12-29 5:22 ` Vasily Kulikov
2012-12-30 11:00 ` Vasily Kulikov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20121229051344.GC4939@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=containers@lists.linux-foundation.org \
--cc=ebiederm@xmission.com \
--cc=kernel-hardening@lists.openwall.com \
--cc=linux-kernel@vger.kernel.org \
--cc=segoon@openwall.com \
--cc=serge.hallyn@canonical.com \
--cc=serge.hallyn@ubuntu.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).