Open causes oops instead of EPERM

From Linux NFS

(Difference between revisions)

Latest revision as of 16:15, 22 October 2010

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>

Open causes oops instead of EPERM

From Linux NFS

Latest revision as of 16:15, 22 October 2010

Contents

About

Symptoms

Cause

Resolution

Views

Personal tools

Navigation

Search

Toolbox

@@ Line 3: / Line 3: @@
 * [https://bugzilla.kernel.org/show_bug.cgi?id=15674 Bug 15674]
 * Reported by: Daniel J Blueman (March 29, 2010)
-* Fixed by:
+* Fixed by: Al Viro (April 8, 2010)
 == Symptoms ==
@@ Line 26: / Line 25: @@
 BUG: unable to handle kernel NULL pointer dereference at 000000000000000b
+...
 </pre>
+== 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 [http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h= ]
+* This problem was fixed by commit [http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=04287f975e68038051eb9c79896866d36610b8e0 04287f975e68038051eb9c79896866d36610b8e0]
 <pre>
+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>
 </pre>