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

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] [day] [month] [year] [list]

Date:	Thu, 17 Apr 2008 11:25:16 +0400
From:	"Cyrill Gorcunov" <gorcunov@...il.com>
To:	"Trond Myklebust" <trond.myklebust@....uio.no>
Cc:	akpm@...ux-foundation.org, linux-kernel@...r.kernel.org
Subject: Re: [patch 1/3] NFS: fix potential NULL pointer dereference

On Thu, Apr 17, 2008 at 8:25 AM, Cyrill Gorcunov <gorcunov@...il.com> wrote:
> On Thu, Apr 17, 2008 at 12:40 AM, Trond Myklebust
>
> <trond.myklebust@....uio.no> 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 ;)

Download attachment "super.diff" of type "application/octet-stream" (2309 bytes)