From: ebiederm@xmission.com (Eric W. Biederman)
To: Dave Jones <davej@redhat.com>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>,
dhowells@redhat.com, "Serge E. Hallyn" <serge@hallyn.com>
Subject: Re: commit_creds oops
Date: Thu, 28 Feb 2013 23:03:33 -0800 [thread overview]
Message-ID: <87vc9b61q2.fsf@xmission.com> (raw)
In-Reply-To: <20130301060732.GA20195@redhat.com> (Dave Jones's message of "Fri, 1 Mar 2013 01:07:32 -0500")
Dave Jones <davej@redhat.com> writes:
> On Thu, Feb 28, 2013 at 04:25:40PM -0800, Eric W. Biederman wrote:
>
> > > [ 89.639850] RIP: 0010:[<ffffffff810784b0>] [<ffffffff810784b0>] commit_creds+0x250/0x2f0
> > > [ 89.658399] Call Trace:
> > > [ 89.658822] [<ffffffff812c7d9b>] key_change_session_keyring+0xfb/0x140
> > > [ 89.659845] [<ffffffff8106c665>] task_work_run+0xa5/0xd0
> > > [ 89.660698] [<ffffffff81002911>] do_notify_resume+0x71/0xb0
> > > [ 89.661581] [<ffffffff816c9a4a>] int_signal+0x12/0x17
> > >
> > > Appears to be..
> > >
> > > if ((set_ns == subset_ns->parent) &&
> > > 850: 48 8b 8a c8 00 00 00 mov 0xc8(%rdx),%rcx
> > >
> > > from the inlined cred_cap_issubset
> >
> > Interesting. That line is protected with the check subset_ns !=
> > &init_user_ns so subset_ns->parent must be valid or subset_ns is not
> > a proper user namespace.
> >
> > Ugh. I think I see what is going on and it is just silly.
> >
> > It looks like by historical accident we have been reading trying to set
> > new->user_ns from new->user_ns. Which is totally silly as new->user_ns
> > is NULL (as is every other field in new except session_keyring at that
> > point).
> >
> > It looks like it is safe to sleep in key_change_session_keyring so why
> > we just don't use prepare_creds there like everywhere else is beyond
> > me.
> >
> > The intent is clearly to copy all of the fields from old to new so what
> > we should be doing is is copying old->user_ns into new->user_ns.
> >
> > Dave can you verify that this patch fixes the oops?
>
> Looks like it. Haven't hit the same thing since applying your patch.
>
> I noticed though that get_user_ns bumps a refcount. Is this what we
> want if we're just copying ?
Yes. commit_creds(new) winds up finding old on the current process
and calling put_cred(old).
put_cred when the count drops to zero winds up calling put_cred_rcu
which calls put_user_ns(old->user_ns);
For the same reason we need an extra count on the user namespace new
so that when it eventually is put and put_user_ns(new->user_ns) is
called we don't have a negative count.
Which is a long of way of saying yes we are adding another reference and
we need to increase the reference count.
Eric
prev parent reply other threads:[~2013-03-01 7:03 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-28 23:43 commit_creds oops Dave Jones
2013-03-01 0:25 ` Eric W. Biederman
2013-03-01 3:06 ` Serge E. Hallyn
2013-03-01 6:07 ` Dave Jones
2013-03-01 7:03 ` Eric W. Biederman [this message]
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=87vc9b61q2.fsf@xmission.com \
--to=ebiederm@xmission.com \
--cc=davej@redhat.com \
--cc=dhowells@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=serge@hallyn.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.