Open causes oops instead of EPERM

From Linux NFS

Revision as of 16:12, 22 October 2010 by Amschuma (Talk | contribs)
Jump to: navigation, search

Contents

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()

Resolution 

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>
Retrieved from "http://wiki.linux-nfs.org/wiki/index.php/Open_causes_oops_instead_of_EPERM"
Personal tools