Bug 253190

Summary: NULL pointer deref in nfs_create
Product: Red Hat Enterprise Linux 4 Reporter: Peter Zijlstra <pzijlstr>
Component: kernelAssignee: Peter Zijlstra <pzijlstr>
Status: CLOSED WONTFIX QA Contact: Martin Jenner <mjenner>
Severity: low Docs Contact:
Priority: low    
Version: 4.5CC: jlayton, lwang, rwheeler, steved
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-06-20 13:32:43 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
serial console output
none
patch required for recent assembler
none
second patch needed to compile on recent userspace none

Description Peter Zijlstra 2007-08-17 12:04:27 UTC
Description of problem:

Unable to handle kernel NULL pointer dereference at 0000000000000350 RIP:
<ffffffffa01e6c5f>{:nfs:nfs_create+303}

Version-Release number of selected component (if applicable):

cvsdist as of 17/08/2007 - head 1.98
build with patches provided below on a rawhide userspace as of a month or so ago

How reproducible:

every time

Steps to Reproduce:
1. install rawhide
2. get rhel4 source
3. apply patches below
4. make CC=/usr/bin/gcc34
5. make CC=/usr/bin/gcc34 modules_install install
6. ensure /etc/fstab includes an NFS mount
7. reboot
8. watch fireworks

  
Actual results:

Unable to handle kernel NULL pointer dereference at 0000000000000350 RIP:
<ffffffffa01e6c5f>{:nfs:nfs_create+303}

Expected results:

successfull mount, mount error at worst.

Additional info:

full trace:
Unable to handle kernel NULL pointer dereference at 0000000000000350 RIP:
<ffffffffa01e6c5f>{:nfs:nfs_create+303}
PML4 76c7b067 PGD 0
Oops: 0000 [1]
CPU 0
Modules linked in: nfs(U) lockd(U) nfs_acl(U) rfcomm(U) l2cap(U) bluetooth(U)
sunrpc(U) tg3(U) md5(U) ipv6(U) cpufreq_ondemand(U) dm_mirr
or(U) dm_mod(U) button(U) battery(U) ac(U) parport_pc(U) lp(U) parport(U)
loop(U) ahci(U) libata(U) sd_mod(U) scsi_mod(U) ext3(U) jbd(U)
ehci_hcd(U) ohci_hcd(U) uhci_hcd(U)
Pid: 1281, comm: mount.nfs Not tainted 2.6.9-prep
RIP: 0010:[<ffffffffa01e6c5f>] <ffffffffa01e6c5f>{:nfs:nfs_create+303}
RSP: 0018:0000010076c23dd8  EFLAGS: 00010202
RAX: 0000000000000000 RBX: 000001007fe01240 RCX: 0000000000000000
RDX: 0000010076c23dd8 RSI: 00000100776d67f0 RDI: 000001007fe01240
RBP: 0000000000000000 R08: 000001007fe01240 R09: 0000000000000000
R10: ffffffff801ff6d8 R11: ffffffffa01e6b30 R12: 00000100776d67f0
R13: 0000000076c23ef8 R14: 0000000000000000 R15: 0000007fbfffff0b
FS:  0000002a95ac16f0(0000) GS:ffffffff80553a00(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000000000350 CR3: 0000000000101000 CR4: 00000000000006e0
Process mount.nfs (pid: 1281, threadinfo 0000010076c22000, task 00000100778fe2b0)
Stack: 00003ef800000001 00000100024f2000 0000000000000000 0000000000000246
       000001007fe01240 0000000000000246 00000100024f2000 0000010076c23e58
       0000000000000000 ffffffff8019b3c0
Call Trace:<ffffffff8019b3c0>{vfs_getattr64+34} <ffffffff8019b5a4>{vfs_lstat64+44}
       <ffffffff8019b8cc>{sys_newlstat+17} <ffffffff80110a8e>{system_call+126}


Code: 48 8b 80 50 03 00 00 48 8b 40 18 ff 50 68 48 89 df 89 c5 e8
RIP <ffffffffa01e6c5f>{:nfs:nfs_create+303} RSP <0000010076c23dd8>
CR2: 0000000000000350
 <0>Kernel panic - not syncing: Oops
 <7>eth0: no IPv6 routers present

Comment 1 Peter Zijlstra 2007-08-17 12:04:27 UTC
Created attachment 161728 [details]
serial console output

Comment 2 Peter Zijlstra 2007-08-17 12:06:01 UTC
Created attachment 161729 [details]
patch required for recent assembler

first patch to allow compilation on recent userspace

Comment 3 Peter Zijlstra 2007-08-17 12:06:56 UTC
Created attachment 161730 [details]
second patch needed to compile on recent userspace

Comment 4 Peter Zijlstra 2007-08-17 12:09:53 UTC
compiled the kernel with nfs build in, gives:

Unable to handle kernel NULL pointer dereference at 0000000000000350 RIP:
<ffffffff801f343f>{nfs_create+303}

[root@taijtu linux-2.6.9]# addr2line -e vmlinux ffffffff801f343f
/home/peter/rh-cvs/kernel/RHEL-4/kernel-2.6.9/linux-2.6.9/fs/nfs/dir.c:1260

which is line 31 below:

  1 /*
  2  * Following a failed create operation, we drop the dentry rather
  3  * than retain a negative dentry. This avoids a problem in the event
  4  * that the operation succeeded on the server, but an error in the
  5  * reply path made it appear to have failed.
  6  */
  7 static int nfs_create(struct inode *dir, struct dentry *dentry, int mode,
  8                 struct nameidata *nd)
  9 {
 10         struct iattr attr;
 11         int error;
 12         int open_flags = 0;
 13
 14         dfprintk(VFS, "NFS: create(%s/%ld, %s\n", dir->i_sb->s_id,
 15                 dir->i_ino, dentry->d_name.name);
 16
 17         attr.ia_mode = mode;
 18         attr.ia_valid = ATTR_MODE;
 19
 20         if (nd && (nd->flags & LOOKUP_CREATE))
 21                 open_flags = nd->intent.open.flags;
 22
 23         /*
 24          * The 0 argument passed into the create function should one day
 25          * contain the O_EXCL flag if requested. This allows NFSv3 to
 26          * select the appropriate create strategy. Currently open_namei
 27          * does not pass the create flags.
 28          */
 29         lock_kernel();
 30         nfs_begin_data_update(dir);
 31         error = NFS_PROTO(dir)->create(dir, dentry, &attr, open_flags);
 32         nfs_end_data_update(dir);
 33         if (error != 0)
 34                 goto out_err;
 35         nfs_renew_times(dentry);
 36         nfs_set_verifier(dentry, nfs_save_change_attribute(dir));
 37         unlock_kernel();
 38         return 0;
 39
 40 out_err:
 41         unlock_kernel();
 42         d_drop(dentry);
 43         return error;
 44 }


Comment 6 Jeff Layton 2007-08-21 14:28:43 UTC
Strange -- it's not clear to me why mount.nfs would be attempting to stat a file
on a NFS filesystem. Once the mount syscall is done, I don't think it tries to
do any access on the fs...

Did this client have heirarchical mounts (nfs mount within a nfs mount)? If so,
that might explain it (since mount.nfs would try to stat the mountpoint).

So I guess you're using nfs-utils from rawhide too? If so, what version is it?
There's an upstream transition to make nfs use string-based mount options.
Perhaps that got enabled for this kernel somehow and it actually allowed the
mount to work?

Comment 7 Jiri Pallich 2012-06-20 13:32:43 UTC
Thank you for submitting this issue for consideration in Red Hat Enterprise Linux. The release for which you requested us to review is now End of Life. 
Please See https://access.redhat.com/support/policy/updates/errata/

If you would like Red Hat to re-consider your feature request for an active release, please re-open the request via appropriate support channels and provide additional supporting details about the importance of this issue.