Open causes oops instead of EPERM

From Linux NFS

About

• Kernel version: 2.6.34-rc1, 2.6.34-rc2
• Bug 15674
• Reported by: Daniel J Blueman (March 29, 2010)
• Fixed by: Al Viro (April 8, 2010)

Symptoms

• User attempts to open a file they do not have permissions for
• We expect EPERM, instead we see an oops
• On local filesystem:

$ touch /tmp/foo
$ sudo chmod 0 /tmp/foo
$ cat /tmp/foo
cat: /tmp/foo: Permission denied

• On NFS filesystem:

$ touch /net/users/daniel/foo
$ sudo chmod 0 /net/users/daniel/foo
$ cat /net/users/daniel/foo
Killed

--- [2]

BUG: unable to handle kernel NULL pointer dereference at 000000000000000b
...

Cause

• nfs4_open_revalidate() did not check the return value of lookup_instantiate_filp()
• Originally, the d_revalidate() call was required to return a boolean 0 or 1. Nowadays it allows the filesystem to return an error value instead.

Resolution

• This problem was fixed by commit 04287f975e68038051eb9c79896866d36610b8e0

commit 04287f975e68038051eb9c79896866d36610b8e0
Author: Al Viro <viro@ZenIV.linux.org.uk>
Date:   Thu Apr 8 00:06:07 2010 +0100

    Have nfs ->d_revalidate() report errors properly
    
        If nfs atomic open implementation ends up doing open request from
    ->d_revalidate() codepath and gets an error from server, return that error
    to caller explicitly and don't bother with lookup_instantiate_filp() at all.
    ->d_revalidate() can return an error itself just fine...
    
    See
        http://bugzilla.kernel.org/show_bug.cgi?id=15674
        http://marc.info/?l=linux-kernel&m=126988782722711&w=2
    
    for original report.
    
    Reported-by: Daniel J Blueman <daniel.blueman@gmail.com>
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>