All of lore.kernel.org
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Oleg Nesterov <oleg@redhat.com>
Cc: "Toralf Förster" <toralf.foerster@gmx.de>,
	"Serge E. Hallyn" <serge@hallyn.com>,
	"Andrey Vagin" <avagin@openvz.org>,
	"Al Viro" <viro@zeniv.linux.org.uk>,
	"Linux NFS mailing list" <linux-nfs@vger.kernel.org>,
	"Stanislav Kinsbursky" <skinsbursky@parallels.com>,
	"J. Bruce Fields" <bfields@fieldses.org>
Subject: Re: fuzz tested user mode linux core dumps in fs/lockd/clntproc.c:131 (nfs in a netns utsns problems?)
Date: Mon, 29 Jul 2013 10:42:57 -0700	[thread overview]
Message-ID: <871u6h45zy.fsf_-_@xmission.com> (raw)
In-Reply-To: <20130729141758.GA8505@redhat.com> (Oleg Nesterov's message of "Mon, 29 Jul 2013 16:17:58 +0200")


Adding some people who pay more attention to nfs in network namespaces
than I usually do.

Oleg Nesterov <oleg@redhat.com> writes:

> On 07/28, Eric W. Biederman wrote:
>>
>> > This untested patch should fix it without any need to worry about
>> > dynamic behavior.
>
> Yeees ;) I was thinking about this change too, but I have no idea
> what this ->nodename actually means for nfs.
>
> If you are going to send this patch - great!

Just batting it around for now, and hoping we have the right combination
of eyeballs look at it.  There are more places in nfs that have
questionable uses of utsname() instead of init_utsname().  So I think we
probably need a more comprehensive patch at the very least.

nfsclnt_reclaim is never called from userspace.
nfsclnt_cancel is called from a callback that seems to have no guarantee
                 of an approprate userspace context.
nfsclnt_proc is called from rpc_ops and I did not spend the time to see
             if that could be a userspace context.

So I really don't think using utsname() aka current->nsproxy->uts_ns
makes sense in nlmclnt_setlockargs.

We most definitely have an inconsistency in nfs.  I am a little hesitant
to suggest my patch because it is likely to have strange effects on nfs
in a network namespace.  On the flip side the code is broken anyway, we
might as well at least use a version that is guarnateed not to cause
a null pointer dereference in the kernel.

This is the first time someone has seen a problem since late 2006 since
Serge updated most of the references to use system_utsname but I think
we have just been lucky.

>> Although I am wondering if we have a few other spots
>> > where the dynamic behavior might be iffy.
>
> Yes. And perhaps the patch which moves exit_task_namespaces() after
> exit_task_work() makes sense anyway (the patch I showed).
>
> (but if you change nlmclnt_setlockargs() then it is not 3.11 material).
>
> The original motivation for 8aac62706 was the leak reported by Andrey,
> but that leak should be also fixed by e7b2c406. "Move exit_task_namespaces()
> from exit_notify() to do_exit()" is still fine imho, the reason for
> exit_task_namespaces() from the middle of exit_notify() has gone away.
>
> But perhaps it would be better if work->func() could use ->nsproxy even
> if the task is PF_EXITING.

So far there is nothing in the nfs code that would suggest allowing
work->func() being able to use ->nsproxy would make this code any
better.  I think that would just paper over the problem we are seeing
right now.

>> > Serge do you remember any of this?
>> >
>> > On a good day I can follow the nfs code but it takes quite a while.  I
>> > feel the same way about filesystems locks so I am not really certain
>> > what is going on.
>> >
>> > Eric
>> >
>> > diff --git a/fs/lockd/clntproc.c b/fs/lockd/clntproc.c
>> > index 9760ecb..6643cfc 100644
>> > --- a/fs/lockd/clntproc.c
>> > +++ b/fs/lockd/clntproc.c
>> > @@ -128,11 +128,11 @@ static void nlmclnt_setlockargs(struct nlm_rqst *req, struct file_lock *fl)
>> >  
>> >         nlmclnt_next_cookie(&argp->cookie);
>> >         memcpy(&lock->fh, NFS_FH(file_inode(fl->fl_file)), sizeof(struct nfs_fh));
>> > -       lock->caller  = utsname()->nodename;
>> > +       lock->caller  = init_utsname()->nodename;
>> >         lock->oh.data = req->a_owner;
>> >         lock->oh.len  = snprintf(req->a_owner, sizeof(req->a_owner), "%u@%s",
>> >                                 (unsigned int)fl->fl_u.nfs_fl.owner->pid,
>> > -                               utsname()->nodename);
>> > +                               init_utsname()->nodename);
>> >         lock->svid = fl->fl_u.nfs_fl.owner->pid;
>> >         lock->fl.fl_start = fl->fl_start;
>> >         lock->fl.fl_end = fl->fl_end;
>> >
>> > Eric  

  reply	other threads:[~2013-07-29 17:43 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-27 10:03 fuzz tested user mode linux core dumps in fs/lockd/clntproc.c:131 Toralf Förster
2013-07-27 13:18 ` [uml-devel] Fwd: " Toralf Förster
2013-07-27 17:00 ` Oleg Nesterov
2013-07-27 17:27   ` Oleg Nesterov
2013-07-28 15:26   ` Toralf Förster
2013-07-28 17:58     ` Oleg Nesterov
2013-07-28 18:56       ` [uml-devel] Fwd: " Toralf Förster
2013-07-28 18:56         ` Toralf Förster
2013-07-29  6:29       ` Andrew Vagin
2013-07-29 13:10         ` Oleg Nesterov
2013-07-29 14:27           ` Andrew Vagin
2013-07-29 14:51             ` Oleg Nesterov
2013-07-29 15:43               ` Andrey Vagin
2013-07-29  0:10   ` Eric W. Biederman
2013-07-29  0:32     ` Eric W. Biederman
2013-07-29 14:17       ` Oleg Nesterov
2013-07-29 17:42         ` Eric W. Biederman [this message]
2013-07-29 18:03           ` fuzz tested user mode linux core dumps in fs/lockd/clntproc.c:131 (nfs in a netns utsns problems?) Oleg Nesterov
2013-07-29 18:17             ` Eric W. Biederman
2013-07-30 21:12           ` J. Bruce Fields
2013-07-30 21:20             ` Myklebust, Trond
2013-09-22 17:03   ` fuzz tested user mode linux core dumps in fs/lockd/clntproc.c:131 Toralf Förster
2013-09-22 17:52     ` Oleg Nesterov

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=871u6h45zy.fsf_-_@xmission.com \
    --to=ebiederm@xmission.com \
    --cc=avagin@openvz.org \
    --cc=bfields@fieldses.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=oleg@redhat.com \
    --cc=serge@hallyn.com \
    --cc=skinsbursky@parallels.com \
    --cc=toralf.foerster@gmx.de \
    --cc=viro@zeniv.linux.org.uk \
    /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.