Re: [patch 1/3] NFS: fix potential NULL pointer dereference

From: Cyrill Gorcunov
Date: Thu Apr 17 2008 - 03:25:27 EST


On Thu, Apr 17, 2008 at 8:25 AM, Cyrill Gorcunov <gorcunov@xxxxxxxxx> wrote:
> On Thu, Apr 17, 2008 at 12:40 AM, Trond Myklebust
>
> <trond.myklebust@xxxxxxxxxx> wrote:
> >
>
>
> > On Thu, 2008-04-17 at 00:19 +0400, Cyrill Gorcunov wrote:
> > > Trond, I've just pointed the problem and its solution (which is seems
> > > to be a bit ugly, according to the rest nfs coding principle). So if
> > > you prefer to have such a check in 'walk_path' function - just say me
> > > that. You choose :) Thanks for comments
> >
> >
> > > > So? The defensive coding principle is that you perform validity checks
> > > > when the pointer is created. Otherwise, we could equally well have added
> > > > the NULL deref check to nfs4_path_walk()...
> >
> > No, your fix was correct, it was just incomplete.
> >
> > The point I was making above was that defensive programming means that
> > _all_ these validity/NULL pointer checks should really be done in
> > nfs4_validate_mount_data and nfs_validate_mount_data. We shouldn't rely
> > on checks in other parts of the code.
> >
> > In fact, as an example: it looks to me as if the lack of a
> > nfs_server.hostname, leads to a lack of nfs_client->cl_hostname, which
> > will eventually cause an Oops if you 'cat /proc/fs/nfsfs/servers', or if
> > you hit the printk in nfs_update_inode(), or various other dprintk()s.
> >
> > Trond
> >
> >
>
> Thanks Trond, I'll remake it ASAP (but can't guarantie that it will be soon ;)
>

Hi Trond,

here is an updated version enveloped (can't send it by inline 'cause I'm in
office now and have to use Web interface to my mail)

Please review (any comments are welcome - as always ;)

Attachment: super.diff
Description: Binary data